The document discusses best practices for unit testing, including making tests trustworthy by testing the right functionality, avoiding test logic, and ensuring code coverage. It recommends making tests maintainable by reusing test code, enforcing isolation between tests, and avoiding multiple asserts. The document also emphasizes creating readable tests through naming, separating asserts from actions, and avoiding magic values.
Boost Fertility New Invention Ups Success Rates.pdf
Dev204 Osherove
1.
2. Unit Testing Good Practices Roy Osherove Chief Architect Typemock DEV204
3. Team Agile - All rights reserved Real World Agenda Making your tests trustworthy Creating maintainable tests Readable tests – last but not least!
4. Team Agile - All rights reserved Make Your tests trust worthy Test the right thing Removing or changing tests Assuring code coverage Avoid test logic Make it easy to run
5. Test the right thing [Test] Public void Sum() { int result = calculator.Sum(1,2); Assert.AreEqual(4,result, “bad sum”); } Team Agile - All rights reserved
6. Team Agile - All rights reserved Removing/Changing tests As rule – don’t change or remove. Always add new tests. Unless: It’s for clarity (functionality stays the same) Test is not needed Test is needed to run differently
7. Team Agile - All rights reserved Assuring code coverage [DEMO] Change production code and see what happens Make params into consts Remove “if” checks – or make into consts If all tests pass - something is missing or something is not needed
8. Team Agile - All rights reserved Avoid Test Logic No Ifs, SWITCH’s or CASE’s Only Create, configure, act and ASSERT Test logic == test bugs Fail first assures your test is correct as well!
9. Team Agile - All rights reserved Make it easy to run Integration vs. Unit tests Configuration vs. “ClickOnce” Laziness is key If some tests fail all the time no one listens One package *always* has to work!
10. Team Agile - All rights reserved Creating maintainable tests Avoid testing private/protected members Re-use test code (Create, Manipulate, Assert) Enforce test isolation Avoid Multiple Asserts
11. Team Agile - All rights reserved Test only publics Testing a private makes your test more brittle Makes you think about the design and usability of a feature Test-First leads to private members after Refactoring, but they are all tested! But sometimes there’s not choice
12. Team Agile - All rights reserved Reuse test code [DEMO] Create objects using common methods (factories) [make_XX] Manipulate and configure initial state using common methods [init_XX] Run common tests in common methods [verify_XX]
13. Team Agile - All rights reserved Enforce test isolation No dependency between tests! Don’t run a test from another test! Run alone or all together in any order Otherwise – leads to nasty “what was that?” bugs
14. Team Agile - All rights reserved Avoid Multiple Asserts Like having multiple tests But the first the fails – kills the others You won’t get the big picture (some symptoms) Hard to name Can lead to more debugging work
15. Team Agile - All rights reserved Creating readable tests Naming a unit test Naming variables Separate Assert from action
16. Team Agile - All rights reserved Naming a unit test Method name State under test Expected behavior/return value Add_LessThanZero_ThrowsException() Another angle: Add_LessThanZero_ThrowsException2()
18. Team Agile - All rights reserved Separate Assert from Action Previous example Assert is less cluttered More readable Allows handling the return value if needed It’s all about reability
20. Team Agile - All rights reserved Make Your tests trust worthy Test the right thing Removing or changing tests Assuring code coverage Avoid test logic Make it easy to run
21. Team Agile - All rights reserved Creating maintainable tests Avoid testing private/protected members Re-use test code (Create, Manipulate, Assert) Enforce test isolation Avoid Multiple Asserts
22. Team Agile - All rights reserved Creating readable tests Naming a unit test Naming variables Separate Assert from action