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. 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);

20. Avoid Multiple Asserts
MVCDev.LinkExtensionsTest L. 334

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

23. Avoid Multiple Mocks

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

32. Magic Values
Unity InjectionMethodFixture

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

39. ArtOfUnitTesting.com

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
royo@bouvet.no
Coaching, mentoring and training
For team leaders, developers, architects and
product owners