Your SlideShare is downloading. ×
Roy Osherove on Unit Testing Good Practices and Horrible Mistakes
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Roy Osherove on Unit Testing Good Practices and Horrible Mistakes

8,467

Published on

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

No Downloads
Views
Total Views
8,467
On Slideshare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
92
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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

×