Exercise: Writing Unit Tests
Three finished classes each hide one bug. Plan scenarios from their requirements, write MSTest tests that find the bugs, and fix the code.
Apprentice · Unit Testing · C# · Updated
This time the code is written, and the tests are yours. Three small classes are finished, but each one hides one bug. Your tests will find them.
Get the exercise code
Open this lesson's GitHub repository, github.com/ask-codey/exercise-writing-unit-tests, also linked from the Exercise box beside the lesson. Click Code, then Download ZIP, and unzip it into your bootcamp folder. Or clone it with Git. Then open TestingExercise.slnx in Visual Studio.
| Class | What it does |
|---|---|
ParkingGarage |
Works out what a stay in a parking garage costs: 15 free minutes, $3.00 for the first hour, $2.00 for each hour after, $20.00 at most |
LibraryCard |
Keeps the books a library card holds: at most 5, never the same title twice |
WordTools |
Counts vowels, and spots palindromes ignoring spaces and upper or lower case |
The full requirements are in the comments at the top of each class and above each method. Each test class in TestingExercise.Tests has one example test, which passes.
What to do
For each class:
- Plan the scenarios from the requirements, as a table: the normal cases and the edges.
- Write one test per scenario, named for it, in Arrange, Act, Assert. Use
[DataRow]where several inputs share a scenario. - Run the tests. A failure is either a mistake in your test or a bug in the class: read the requirement again to decide which.
- Fix the bug in the class, and run the tests until they all pass.
There are three bugs in all, one per class.
Hints
- Edges find bugs. For "at most 5 books", test the 4th, 5th and 6th books. For "the first hour", test 59, 60 and 61 minutes.
- Test what the requirements say, not what the code does. Work out each expected value by hand, from the requirement.
- Give each Assert a message that states the requirement, so a failure explains itself.
- Never change a correct test to make it pass. If the test matches the requirement, the code is wrong.
When you're done
Every test passes, and each class has a test that would have caught its bug. Put the bug back for a moment, and watch your test turn red: that's the proof your test works.
Submit your exercise
The exercise is how you finish this lesson. When your work is done, put it on GitHub in a repo of your own, then submit that repo's address here.
On GitHub, click +, then New repository. Name it (for example
exercise-writing-unit-tests), choose Public, and click Create repository. Leave out the README: your folder already has one.In a terminal in your exercise folder (Git Bash on Windows), send your work to your new repo. If you downloaded the ZIP:
git init -b main git add . git commit -m "My solution" git remote add origin https://github.com/your-name/exercise-writing-unit-tests.git git push -u origin mainIf you cloned the starter instead, point your copy at your own repo, then commit and push:
git remote set-url origin https://github.com/your-name/exercise-writing-unit-tests.git git add . git commit -m "My solution" git push -u origin mainPaste your repo's address, such as
https://github.com/your-name/exercise-writing-unit-tests, into Submit your exercise on this page. The site checks that the repo is public and holds your commits, and then the lesson is complete.
Changed something after you submitted? Push it, and submit again: your latest submission is the one that counts.
So what
You've just done what testers and developers do every day: turned requirements into scenarios, scenarios into tests, and failing tests into fixed code.