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

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

Questions?

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.

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?

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

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

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

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

Act Typically_only_1_line_of_code();

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

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?!)

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

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?)

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

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

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

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

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