Unit tests = maintenance hell ?

Unit Tests = Maintenance Hell ?

Thibaud DESODT
@tsimbalar

This talk
• About Unit-Testing
– Why we do it
– Why it can slow you down
– How to ease the maintenance

• Include :
– .NET-based examples / tools
– … can be applied to other platforms

Value of Unit tests
• Benefits
Value of Unit tests

–
–
–
–
–
“toy”
projects

Avoid introducing bugs
Executable documentation
Regression detection
Know when to stop
Reduce fear / allow
refactoring
–…

Unit-tests help build CONFIDENCE

Codebase size

But when the codebase grows …

Quantity of Test Code
• Prod Code vs Test Code Ratio
– from 1:1 to 1:5 !

More Test Code than Prod Code !
• Muliplied efforts :
– New Code
– Changing existing code

Lower Quality of Test Code
• Viewed as less important than Prod Code
– “Write Once”
– Duplication / Copy+Paste
– Less refactoring / improvements
– Hard to read/understand

• Technical Debt reduction has less priority

Cost of Unit tests

Cost of Unit Tests

Unit-tests introduce FRICTION

Codebase size

Value vs Cost of Unit tests

ROI
WTF?

Codebase size

Unit Tests = Maintenance Hell ?
It can be … but it does not have to !

Maintainability of codebase

Solution 1 : give up on Unit Tests
“Legacy Code is code without Tests”
Michael Feathers
Working Effectively with Legacy Code

Codebase size

WIN !

Value vs Cost of Unit tests

Solution 2 : reduce the cost
of test maintenance !

Codebase size

REDUCING TEST MAINTENANCE
COSTS

Tools to manage thousands of tests
–
–
–
–

Exploring tests / results
Run All
Run/Debug Current Test
Run All Tests in current
Test Class
– Re-run last executed
tests
–…

• VS2012 Test Explorer
– Just kidding !

• Telerik JustCode
• JetBrains ReSharper

Continuous Testing
• NCrunch !
–
–
–
–

Runs tests continuously
Reports results without rebuilding or saving the files !
Impacted tests are run first
Tests run in parallel

• Expensive but worth it ! (159$/289$)
– Give it a try http://www.ncrunch.net/
– Free alternative : http://continuoustests.com/

Define conventions
Convention

Choice

Test Projects

[ProjectNamespace].Tests

Test Classes

One/class to test: [TestedClass]Test

Test Methods

[MethodName]_with_[Condition]_[ExpectedOutcome]

Structure

Arrange/Act/Assert or Given/When/Then

Helper methods In Test Class (private static)
In Test Project in namespace TestUtils
In dedicated project « Test Support »

Which convention you choose does not matter,
as long as it’s used by everybody !

Use « standard » variable names /
prefixes
• Common concepts :
– sut (System Under Test)
– actual (result of the action)
– expected (expected value for the result)

• Benefits :
– Makes tests more homogenous
– No need to think of it when writing the test
– Resistant to class renaming !

Typical structure
[TestMethod]
public void SomeMethod_with_SomeConditions_must_DoSomething()
{
// Arrange
var sut = MakeSut();
var expected = "what it should return";
// Act
var actual = sut.DoSomething();
// Assert
Assert.AreEqual(expected, actual, "Should have done something");
}

TIP #3 : MAKE WRITING TESTS
CHEAP AND EASY !

Use templates / snippets
• Commonly created items :
– Test Class
– Test Methods
– Test Helper Methods

• … and share them with the team !
• Examples :
– aaa, aae, any …

TIP #4 : MAKE YOUR TESTS
REFACTORING-FRIENDLY

It will change !
“The only constant is change”
Heraclitus of Ephesus
5th century BC

• In 3 minutes / days / weeks …
• Be ready !

Constructors
• Dependency Injection entry point
– Changes when dependencies are added/removed
– Impact in every test !

• Encapsulate it in a helper Method

MakeSut()
private static ClassToTest MakeSut(
IDependency1 dep1 = null,
IDependency2 dep2 = null)
{
dep1 = dep1 ?? new Mock<IDependency1>().Object;
dep2 = dep2 ?? new Mock<IDependency2>().Object;
return new ClassToTest(dep1, dep2);
}

– Default value for dependencies
– Adding dependencies does not impact tests

Test Data creation
• Classes will change
– New properties
– Updated constructors ….

• Automate generation of « auxiliary » test
objects

AutoFixture
• Creates instances of
classes

var fixture = new Fixture();
var user = fixture.Create<User>();

– Populates constructor
arguments
– Populates properties
– Recursive
– Values derived from
Property names

> Install-Package AutoFixture
https://github.com/AutoFixture/AutoFixture/wiki/Cheat-Sheet

Test-specific comparison
• Comparing objects is common
– Actual vs expected
– Should not override Equals() for the tests

• Adding properties can break comparison

Semantic Comparison
var actualUser = new User(12, "john@rambo.com");
var expectedUser = new User(13, "tibo@desodt.com");
actualUser.AsSource().OfLikeness<User>().ShouldEqual(expectedUser);
Ploeh.SemanticComparison.LikenessException: The provided value
ProductionCode.Lib.Data.User did not match the expected value
ProductionCode.Lib.Data.User. The following members did not match:
- Id.
- EmailAddress.

actualUser.AsSource().OfLikeness<User>()
.Without(u=> u.Id)
.ShouldEqual(expectedUser);

> Install-Package SemanticComparison

Working with many Unit Tests
• … is hard
• Requires extra care
– Up-front
– During code maintenance

• But pain can be reduced
by:
– Appropriate tools
– Good habits

TIPS
#1 Proper Tools
– Good Test Runner
– Continuous Tests

#2 Get organized
– Conventions
– Naming

#3 Make Writing Tests Cheap
and easy
– Templates/snippets

#4 Prepare for changes
– Encapsulate constructors
– Automate object Creation
– Automate object comparison

Recommended read
• xUnit Test Patterns: Refactoring Test
Code by Gerard Meszaros
– http://xunitpatterns.com/

• Zero-Friction TDD by Mark Seemann
– http://blog.ploeh.dk/2009/01/28/ZeroFrictionTDD/

THANKS !
QUESTIONS ?
Thibaud DESODT
@tsimbalar

Unit tests = maintenance hell ?

More Related Content

What's hot (20)

Similar to Unit tests = maintenance hell ? (20)

Recently uploaded (20)

Unit tests = maintenance hell ?

Editor's Notes