History, Characteristics and Frameworks Unit Tests History, Characteristics and Frameworks Copyright © 2016-2018 – Curt Hill

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 © 2016-2018 – Curt Hill

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 © 2016-2018 – Curt Hill

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 © 2016-2018 – Curt Hill

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 © 2016-2018 – Curt Hill

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 © 2016-2018 – Curt Hill

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 © 2016-2018 – Curt Hill

Copyright © 2016-2018 – Curt Hill XP 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 © 2016-2018 – Curt Hill

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 © 2016-2018 – Curt Hill

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 © 2016-2018 – Curt Hill

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 © 2016-2018 – Curt Hill

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 © 2016-2018 – Curt Hill

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 © 2016-2018 – Curt Hill

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 © 2016-2018 – Curt Hill

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 © 2016-2018 – Curt Hill

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 © 2016-2018 – Curt Hill

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 © 2016-2018 – Curt Hill

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 © 2016-2018 – Curt Hill

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 © 2016-2018 – Curt Hill

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 © 2016-2018 – Curt Hill

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 © 2016-2018 – Curt Hill

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 © 2016-2018 – Curt Hill

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 © 2016-2018 – Curt Hill