Roy Osherove on Unit Testing Good Practices and Horrible Mistakes

14,408 views
11,068 views

Published on

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
14,408
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
126
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

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)
  10. Another logic example:MVCDev.HtmlHelperTest.GetHttpContext()
  11. Don’t repeat production logic String user = “a”; String password= “b”; String SomeResult = UnderTest.CreateMessage(user,password); Assert.AreEqual( user + “,” + password, SomeResult);
  12. Dont 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);
  19. Avoid Multiple AssertsMVCDev.LinkExtensionsTest L. 334
  20. 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
  21. Avoid Multiple Mocks
  22. Creating readable tests Structure No Magic values In test In mockstub Naming a unit test Naming variables Separate Assert from action
  23. Structure Are the tests easy to find? Can you find a test for a class, or a method?
  24. Setup Mystery
  25. Bad Naming
  26. No Magic Values Assert.AreEqual(1003, calc.Parse(“-1”)); Int parseResult = calc.Parse(NEGATIVE_ILLEGAL_NUMBER); Assert.AreEqual( NEGATIVE_PARSE_RETURN_CODE, parseResult)
  27. Hidden Values
  28. Magic values in Fakes
  29. Magic ValuesUnity InjectionMethodFixture
  30. Call it what it is (mockstubfake) Most “Mocks” are actually stubs. If it can be both, call it “Fake”
  31. Naming a unit test Method name State under test Expected behavior/return value Add_LessThanZero_ThrowsException() Another angle: Add_LessThanZero_ThrowsException2()
  32. Naming
  33. Separate Assert from Action Assert is less cluttered More readable Allows handling the return value if needed It’s all about readability
  34. Input Values Should Differ X.Divide (1,1) X.Divide (1,2) X.Check(“1,1”) X.Check(“1,2”)
  35. Readable Maintainable Trustworthy
  36. ArtOfUnitTesting.com
  37. Song?
  38. This is a test line
  39. Looks like you’re doing fine
  40. Time for a song of mine
  41. Hello DB My Old Friend
  42. 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…
  43. FOR VIOLENCE
  44. Man, whoever wrote this codeThat bastard’s gonna hit the roadNow the customer is gonna sueInstead of red, my face is turning blueAnd it seems like there is no way out of this.
  45. There’s just a hiss.I guess it’s time, for violence..
  46. I’m angry and I want a nameThat DBA should be ashamed
  47. What’s that you’re saying?It’s ME to blame?That database was my own sick game?
  48. Oh that’s right.It was me who did the designIt was mine.I guess it’s time…
  49. FOR SILENCE.
  50. Thank You royo@bouvet.no Coaching, mentoring and training For team leaders, developers, architects and product owners

×