1. History, Characteristics and Frameworks
Unit Tests
History, Characteristics and Frameworks
Copyright © – Curt Hill

2. Copyright © 2016-2018 – Curt Hill
Introduction
Unit testing is the testing of a specific module
Does this module fulfill its responsibilities?
Local or composite responsibilities
This is usually applied to a class
Each method has multiple tests applied
The class passes or fails
Copyright © – Curt Hill

3. Copyright © 2016-2018 – Curt Hill
Two possibilities
Suppose that class A communicates with class B
That is A calls a method of B
The unit test may test A using the current version of B
The unit test may test A with a stub or mock object for B
Considered in next screen
There are pros and cons for both that will be considered later
Copyright © – Curt Hill

4. Copyright © 2016-2018 – Curt Hill
Stubs
Stubs are functions that mostly return an expected result without doing the calculation
If I know that sqrt will be called with 4 I code the following stub double sqrt(double d) {return 2;}
This could be enhanced to have ifs that check input and return accordingly
In addition a stub might record to a log what it received
Copyright © – Curt Hill

5. Copyright © 2016-2018 – Curt Hill
Mock Objects
A class full of stubs
Like a stub stands in for a working function a mock object stands in for a real object
This can be only for testing or it can stand in for the object before it is written
Its private data and methods mostly provide for logging the methods called and the values received
It isolates a class from other objects
Copyright © – Curt Hill

6. Unit Test Characteristics
Only the unit in question is being tested
We get it right without respect to the entire application
Integration testing is the name applied to tests that consider the entire program
Integration testing is necessary since unit testing cannot consider all possibilities
Copyright © – Curt Hill

7. Copyright © 2016-2018 – Curt Hill
More
Unit testing is often tedious, requiring patience and thoroughness
It may be done manually but it is usually better to automate it
There are several unit testing frameworks available
Will be considered later in the presentation
Copyright © – Curt Hill

8. Copyright © 2016-2018 – Curt HillXP
XP did not devise unit tests they predate that paradigm
They do require unit tests and it is one of XP’s precepts
Other agile methods use these as well
XP believes that unit tests are a deliverable
They are committed to version control
They are retained for the life of the project
Every change reruns them
Copyright © – Curt Hill

9. Copyright © 2016-2018 – Curt Hill
Michael Feathers
Asserts that unit tests should follow a number of rules
His opinions are based on unit tests that take a very long amount of time to run, which is not uncommon
The long running time discourages testers from using them, which defeats the whole purpose
He is a believer in the stub or mock object approach
Copyright © – Curt Hill

10. Copyright © 2016-2018 – Curt Hill
It is not a unit test if:
It talks to the database
It communicates across the network
It touches the file system
It can't run at the same time as any of your other unit tests
You have to do special things to your environment (such as editing configuration files) to run it
Copyright © – Curt Hill

11. Copyright © 2016-2018 – Curt Hill
Commentary
All of the above cause the unit test to be slow
It may be more work to create a stub/mock object that enables a class to be tested independently of all other classes
The payoff is that our unit tests can be much faster
We save the rest for the integration test
If the real object does not involve these issues it may be used
Copyright © – Curt Hill

12. Charles Miller’s Rules
Write the test first
Never write a test that succeeds the first time
Start with the null case, or something that doesn't work
Don't be afraid of doing something trivial to make the test work
Loose coupling and testability go hand in hand
Recall Michael Feather’s comments
Use mock objects
Copyright © – Curt Hill

13. Copyright © 2016-2018 – Curt Hill
Write Test First
Write the test
Write just enough code for it to compile
It should fail
Write just enough code to make the test succeed
Go back to start and write more tests
Copyright © – Curt Hill

14. Never write a test that succeeds the first time
In the previous scenario the minimal object code was written to allow compilation
If the test succeeds with this the test is wrong
If a test runs the first time you should be suspicious
Code never runs the first time!
Copyright © – Curt Hill

15. Start with the null case, or something that doesn't work
Is there a circumstance in which the method should return null, or an empty collection, or an empty array?
Code that test case first
This replicates a lookup that does not exist
These are often the simplest
Copyright © – Curt Hill

16. Don't be afraid of doing something trivial to make the test work
This corresponds to the class code for the previous test code
This should change the test from failing to succeeding
Getting the trivial cases to work is important for getting the more complicated ones to work
Copyright © – Curt Hill

17. Copyright © 2016-2018 – Curt Hill
Frameworks
A number of unit test frameworks exist that assist the automation process
The first was an Sunit
Described in 1989 by Kent Beck
This gave rise to numerous others
JUnit for Java
Runit of Ruby
Collectively called xUnits
Kent Beck’s Guide to Better Smalltalk
Copyright © – Curt Hill

18. Copyright © 2016-2018 – Curt Hill
xUnit Architecture
xUnits share a typical architecture which has the following pieces
Test runner – the executable that runs the test
Test case – ancestor of all unit tests
Test fixtures – set of preconditions needed for the test
Test suites – set of test that share the fixtures
Copyright © – Curt Hill

19. Architecture continued
Test execution contains two methods
setup() prepares
teardown() cleans up
Test result formatter
The test runner produces results
This produces a formatted result
Assertions
Verifies that the correct results produced
Copyright © – Curt Hill

20. Copyright © 2016-2018 – Curt Hill
xUnits
According to WikiPedia most languages have more than one
Ada has 5
C++ has 72
Java has 41
JavaScript has 44
.net languages have 25
PhP has 17
Python has 9
All have same goal, but not all use same architecture
Copyright © – Curt Hill

21. Test Driven Development
A derivation of XP
Based on the notion of unit tests
For each change a test is written first
Often the construction of the test shows the ambiguities of the change request
Only after the test is constructed is the code created or modified
Focus of development is minimal code that passes the test
Copyright © – Curt Hill

22. System Development Methodologies
Several System Development Methodologies require the use of automated unit tests
XP for example
Test Driven Development, like Kanban, may be applied to any software development paradigm
Copyright © – Curt Hill

23. Copyright © 2016-2018 – Curt Hill
Final Summary
Unit tests are generally an automated test that tests a single class with its methods
If the class calls methods from other classes
We may use stubs or mock objects
We may also use the working classes
A class that uses a network or a database may not be easy to test
Establishing the state is hard
We will look at a unit test framework later
Copyright © – Curt Hill