Roy Osherove on Unit Testing Good Practices and Horrible Mistakes
Download as PPTX, PDF7 likes25,118 views
Roy Osherove provides training courses on topics like test-driven development (TDD), behavior-driven development (BDD), and consulting/coaching services. He discusses test reviews as an alternative to code reviews that can be quicker and help learning teams. The presentation focuses on creating tests that are trustworthy, maintainable, and readable through techniques like avoiding test logic, not repeating production logic, separating unit and integration tests, and using readable structures, naming, and avoiding magic values.
![Reuse test code
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]](https://image.slidesharecdn.com/utpractices-1hrtalknosong-130116150053-phpapp02/85/Roy-Osherove-on-Unit-Testing-Good-Practices-and-Horrible-Mistakes-16-320.jpg)
Roy Osherove on Unit Testing Good Practices and Horrible Mistakes
- 1. @RoyOsherove
- 2. What I do (artOfUnitTesting.com) Courses on TDD, BDD in JS, Ruby, Java and C# TDD (EpiServer TDD, MVC TDD…) Courses for Team Leaders (5whys.com) Consulting & coaching through Bouvet Contact.osherove.com Team Agile - All rights
- 3. Real World Agenda Test Reviews Making your tests TRUSTworthy Creating MAINTAINable tests READable tests RTFM
- 4. Test review vs. code review Understand intent of developer 10 times quicker Drill in when needed Important for learning teams Helps drive change
- 5. Readable Maintainable Trustworthy
- 6. Make Your tests trust worthy Make it easy to run Removing or changing tests Assuring code coverage Avoid test logic Avoid Manual StubMock Logic Don’t Repeat Production Logic
- 7. Separate Unit From Integration Tests
- 8. Code coverage? Worthless without a code review 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
- 9. Avoid test logic (MS Unity)
- 11. Don’t repeat production logic String user = “a”; String password= “b”; String SomeResult = UnderTest.CreateMessage(user,password); Assert.AreEqual( user + “,” + password, SomeResult);
- 12. Don't use things that keep changing DateTime.Now Random Environment.TickCount Threads Etc..
- 13. Tests that keep changing: NerdDinner
- 14. Creating maintainable tests Avoid testing private/protected members Re-use test code (Create, Manipulate, Assert) Enforce test isolation Test One Thing Avoid Multiple Asserts One mock per test Use “relaxed” or “Non strict” mocks and stubs
- 15. Test only publics “Unit” testing == “Unit Of Work Testing” 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
- 16. Reuse test code 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]
- 17. 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
- 18. Avoid Multiple Asserts On different objects String user = “a”; String password= “b”; String SomeResult = UnderTest.CreateMessage(user,password); Assert.AreEqual( user + “,” + password, SomeResult); Assert.AreEqual (1,UnderTest.MessageCount);
- 22. 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
- 24. Creating readable tests Structure No Magic values In test In mockstub Naming a unit test Naming variables Separate Assert from action
- 25. Structure Are the tests easy to find? Can you find a test for a class, or a method?
- 26. Setup Mystery
- 27. Bad Naming
- 28. No Magic Values Assert.AreEqual(1003, calc.Parse(“-1”)); Int parseResult = calc.Parse(NEGATIVE_ILLEGAL_NUMBER); Assert.AreEqual( NEGATIVE_PARSE_RETURN_CODE, parseResult)
- 29. Hidden Values
- 30. Magic values in Fakes
- 33. Call it what it is (mockstubfake) Most “Mocks” are actually stubs. If it can be both, call it “Fake”
- 34. Naming a unit test Method name State under test Expected behavior/return value Add_LessThanZero_ThrowsException() Another angle: Add_LessThanZero_ThrowsException2()
- 35. Naming
- 36. Separate Assert from Action Assert is less cluttered More readable Allows handling the return value if needed It’s all about readability
- 37. Input Values Should Differ X.Divide (1,1) X.Divide (1,2) X.Check(“1,1”) X.Check(“1,2”)
- 38. Readable Maintainable Trustworthy
- 40. Song?
- 41. This is a test line
- 42. Looks like you’re doing fine
- 43. Time for a song of mine
- 44. Hello DB My Old Friend
- 45. Hellow DB my old friend I need to work with you again That stored procedure ain’t working well Whoever wrote that trigger should go to jail And that index , it is slower than a snail What the hell? I guess it’s time…
- 46. FOR VIOLENCE
- 47. Man, whoever wrote this code That bastard’s gonna hit the road Now the customer is gonna sue Instead of red, my face is turning blue And it seems like there is no way out of this.
- 48. There’s just a hiss. I guess it’s time, for violence..
- 49. I’m angry and I want a name That DBA should be ashamed
- 50. What’s that you’re saying? It’s ME to blame? That database was my own sick game?
- 51. Oh that’s right. It was me who did the design It was mine. I guess it’s time…
- 52. FOR SILENCE.
- 53. Thank You [email protected] Coaching, mentoring and training For team leaders, developers, architects and product owners