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
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
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
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
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()
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…
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.