1. Unit Testing in a Team Sparkhound Presents by Steve Schaneville
August 6, 2016

2. References / Bibliography
Clean Code – Robert Martin
Art of Unit Testing (Second Edition) – Roy Osherove
Dependency Injection in .NET – Mark Seemann
Working Effectively in Legacy Code – Michael Feathers

3. Questions?

4. Why This Topic
I (and a team of people much sharper than me) tried to bring unit testing into an established and sizable development shop on multiple occasions in the past, and we failed repeatedly...
… and then we finally succeeded.

5. What Will We Wiscuss? Benefits of unit testing
What makes a unit test a unit test? (differences between unit tests and other kinds of tests)
Patterns and conventions
When should I run my tests?
What should I test, and how many tests should I write?
Should I use code coverage?
How do I train my team?

6. Benefits of Unit Testing
Refactor code with impunity
Get to rev 1 much faster - you never fire up the UI while coding the back end
Ex: AMS3’s Patient Chart Sync
Ex: Coachwell’s GetActionCenterDetailsCommand

7. What makes a unit test a unit test?
Target only a single behavior
Contain only a single ASSERT
Have no external dependencies
Require no environment configuration
If you project builds, all tests will run and pass (seriously, no dependencies!)
Run FAST
50ms is too long
Typically <10ms
Invokes a public method (no privates or protecteds!)
Any test that does not meet this criteria is not a unit test

8. Patterns and Conventions
Where should I put my test class?
How should I name my test class?
TargetName_Tests
How should I name my test method?
TargetMethod_WithSomeConditions_YieldsSomeResult
How should my test method be organized? (Answer: 3A)
Arrange, Act, Assert
Method name: Act_Arrange_Assert (for sorting)
Space between each section

9. Arrange Refactor common arrange blocks into reusable methods
Arrange everything as “valid”, then back off
Don’t use testing framework initialization methods
Arrange database repositories, don’t arrange your DbContext
It’s harder to reason about arranging the DbContext
Unit tests are not testing production code if you arrange the DbContext

10. Act
Typically_only_1_line_of_code();

11. Assert Only a single assert per test Hard-code your “expected” values
Don’t be TOO specific (ex. error messages)
Be careful not to test your implementation
But DO test your integration
Fluent Assertions
Assert on lists, entire objects, etc.
Excellent messages for failed assertions

12. What tests should I write?
Cover behaviors, not code
Think “possible paths through” the code in test
Rule of thumb: one test per line of code (seriously?!)

13. When should I run my tests?
During the gated build
When I first open any project
When I change any code
Just before I check in
Every time I blink

14. What code should my tests target?
What is a “unit”?
Logical piece of functionality… typically a class (and my classes only have 1 public method!)
What should I not bother testing?
Exceedingly simple code, such as simple data-only property getters and property setters
Generated code
Layers in which the value of testing offers little value (ex. the service layer may be pass-through only)
The entire app from service layer up? (how new is our team at this?)

15. Should I track code coverage?
Use code coverage as a guide to determine what pieces of code you’ve missed that may need tests
Do not require the team to meet a certain level of code coverage

16. Train the Team Get buy-in Don’t require 100% Don’t require 50%
Practice, and ramp up slowly
Debate

17. How do I write testable code to begin with?
Answer: Create seams
What is a seam and how do I create them?
Dependency Injection
Constructor Injection
Property Injection
Method Injection
Inheritance
Sensing object

18. Fakes! What are fakes? Hand-rolled fakes (with demo) Faking Frameworks
Stubs – substitute for a dependency in the target code
Mocks – a stub that is used in an assertion in your test
Hand-rolled fakes (with demo)
Faking Frameworks
FakeItEasy (with demo)
Moq
Tons of others

19. Unit Testing in Legacy Code
Everything we’ve discussed today requires that the code base be built with testing in mind (read: Dependency Injection)
Working Effectively in Legacy Code – Michael Feathers
BRDNUG – I’ll be giving a user group talk on this topic