Three parts of a test
This learning hour is about Arrange - Act - Assert and uses a simpler exercise than AAA. It could be done as a follow-up to Tests Have Assertions if you didn’t finish the whole exercise in one session.
Learning Goals
- recognize a well-structured test case.
- use the three parts when designing a test case.
Session Outline
- 5 min connect: What is an automated unit test
- 10 min concept: Three parts of a test
- 25 min concrete: Write some tests
- 10 min conclusions: Showcase and discuss test design
- 5 min conclusions: When to do this
Connect: Three facts
What is the most important job of a unit test? Give me your top three ideas (three facts).
Concept: Three parts of a test
An automated test usually has three kinds of code.
- Arrange - set up the test data and environment your function will need
- Act - exercise the function you want to test
- Assert - verify it did the right thing by checking what happened
Normally in a unit test you only have one of each section, and they come in that order. If you want to check another thing, add a new test case. Don’t just build more act-assert steps onto the same test case.
Concrete
Write some test cases for some existing code that has well-marked bugs in. For example CalcStats. Be sure to structure your test cases using Arrange - Act - Assert. Write tests that fail because of the bugs, and which pass when you fix the bugs.
Conclusions: Test Design Guidelines
Showcase the various tests people have written. Take some screenshots and put them on the shared online whiteboard. Annotate them with what is good about these designs. Highlight what’s good, also mention things that could be improved if you think it’s important.
Conclusions
Can you think of any advantages of structuring your tests this way, with Arrange - Act - Assert? Are there any situations where it wouldn’t be a good idea? When should you use this?