Unit TestingOverview and Best Practices

What’s unit testing?

• Software development process.

• Tests smallest parts of an application.

• Individually and independently.

• Always automated.

Why unit testing?

• Quality

• Test automation

• Bug catching

Why unit testing? cont.

• Documentation

• Design Improving

• Safe Refactoring

• Avoid fear of changes

What’s an unit test?

• Automated piece of code.

• Checks assumptions (state and/or behaviour).

• Unit of work.

• Single end result.

What’s an unit of work?

• Single logical functional use case.

• Public interface.

• A single method, a whole class or multiple classes.

Other levels of testing

• Integration test

• System/E2E test

A good unit test is:

• Fully automated

• Independent

• Isolated

• Deterministic

A good unit test is also:

• Fast

• Unitary

• Readable

• Maintainable

• Trustworthy

Unit Testing Frameworks

• xUnit

• SUnit

xUnit Architecture

• Test Runner

• Test Case

• Test Fixtures

xUnit Architecture cont.

• Test Suites

• Assertions

• Test Result Formatter

A (N)unit test structure

[TestFixture]public class SimpleTest{

[Test]public void ShouldDoSomething(){

//Given

//When

//Then

}}

A simple class (SUT)public class Calculator{

private double amount;

public Calculator (){

amount = 0;}

public void SetAmount(double value){

amount = value;}

public double GetAmount(){

return amount;}

public Calculator Add(double value) {

amount += value;return this;

}}

A simple (N)unit test[TestFixture]public class CalculatorTest{

[Test]public void ShouldAddAPositiveAmount(){

//GivenCalculator calculator = new Calculator();var initialAmount = 10;var amountToAdd = 30;var expectedAmount = 40;calculator.SetAmount(initialAmount);

//Whencalculator.Add(amountToAdd);

//ThenAssert.AreEqual(expectedAmount, calculator.GetAmount());

}}

A class with a dependencypublic class Calculator

{private double amount;private MathProcessor mathProcessor;

public Calculator (MathProcessor mathProcessor){

amount = 0;self.mathProcessor = mathProcessor;

}

public void SetAmount(double value){

amount = value;}

public double GetAmount(){

return amount;}

public Calculator Add(double value) {

if (value > 1000000) { amount = mathProcessor.Add(amount, value);

} else { amount += value; }

return this;}

}

A test using mock[TestFixture]public class CalculatorTest{

[Test]public void ShouldUseMathProcessorForLargeNumbers(){

//Givenvar initialAmount = 10;

var amountToAdd = 3000000;var expectedAmount = 3000010;var mathProcessorMock = new Mock<MathProcessor>();

mathProcessorMock.Setup(m=>m.Add()). Returns(expectedAmount); Calculator calculator = new Calculator(mathProcessor.Object);

calculator.SetAmount(initialAmount);//Whencalculator.Add(amountToAdd);//ThenmathProcessorMock.Verify(m=>m.Add(initialAmount,

amountToAdd));}

}

Test Doubles

• Satisfy SUT dependencies when the actual implementation can not be used.

Test Doubles• The most common test doubles are the

following:

• Dummies

• Fakes

• Stubs

• Spies

• Mocks

Mocks vs. Stubs

• You DO NOT assert against stubs.

• You MUST assert against mocks.

State verification

• Assert against the object state to make sure its state is correct.

Behaviour verification

• Assert against mock(s) to check if the expectations were met.

• Make sure the SUT is calling its dependencies correctly.

State vs Behaviour

• When to test state?

• When to test behaviour?

State vs Behaviour cont.

• Excessive use of mocking can lead to the following issues:

• Tests can be harder to understand.

• Tests can be harder to maintain.

• Tests can become less trustworthy.

• Tests can become tautological.

Unit Tests Myths• It’s a waste of time

• It makes changes more difficult to make

• It slows down the development process

• But it’s such simple code, why write a test?

• Unit testing increases development costs

Making your code testable

• Avoid using singletons and/or static classes and methods.

• If it’s not possible, try using DI.

• Avoid too many dependencies (more than 3).

Questions?

Thank you!

References• The Art of Unit Testing, 2nd Edition, Osherove,

Roy

• xUnit Test Patterns, Meszaros, Gerard

• http://googletesting.blogspot.com.br/search/label/TotT

• http://artofunittesting.com/