Unit testing basics
-
Upload
joao-paulo-leonidas-fernandes-dias-da-silva -
Category
Software
-
view
207 -
download
0
Transcript of Unit testing basics
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/