10, JUnit
Apr 2009
Test suites
Obviously you have to test your code to get it working in the first place
You can do ad hoc testing (running whatever tests occur to you at the moment), or You can build a test suite (a thorough set of tests that can be run at any time) Its a lot of extra programming
Disadvantages of a test suite
This is true, but use of a good test framework can help quite a bit False--Experiments repeatedly show that test suites reduce debugging time more than the amount spent building the test suite
You dont have time to do all that extra work
Advantages of a test suite
Reduces total number of bugs in delivered code Makes code much more maintainable and refactorable
This is a huge win for programs that get actual use!
2
XP approach to testing
In the Extreme Programming approach,
Tests are written before the code itself If code has no automated test case, it is assumed not to work A test framework is used so that automated testing can be done after every small change to the code
This may be as often as every 5 or 10 minutes
If a bug is found after development, a test is created to keep the bug from coming back Fewer bugs More maintainable code Continuous integration--During development, the program always works--it may not do everything required, but what it does, it does right
3
Consequences
Rhythm
There is a rhythm to developing software unit tests first. You create one test to define some small aspect of the problem at hand. Then you create the simplest code that will make that test pass. Then you create a second test. Now you add to the code you just created to make this new test pass, but no more! Not until you have yet a third test. You continue until there is nothing left to test. http://www.extremeprogramming.org/rules/testfirst.html
4
JUnit
JUnit is a framework for writing tests
JUnit was written by Erich Gamma (of Design Patterns fame) and Kent Beck (creator of XP methodology) JUnit uses Javas reflection capabilities (Java programs can examine their own code) JUnit helps the programmer:
define and execute tests and test suites formalize requirements and clarify architecture write and debug code integrate code and always be ready to release a working version
JUnit is not yet (as far as I know) included in Suns SDK, but an increasing number of IDEs include it BlueJ, JBuilder, and Eclipse now provide JUnit tools
5
Terminology
A test fixture sets up the data (both objects and primitives) that are needed to run tests
Example: If you are testing code that updates an employee record, you need an employee record to test it on
A unit test is a test of a single class A test case tests the response of a single method to a particular set of inputs A test suite is a collection of test cases A test runner is software that runs tests and reports results An integration test is a test of how well classes work together
JUnit provides some limited support for integration tests
6
Structure of a JUnit test class
Suppose you want to test a class namedFraction publicclassFractionTest extendsjunit.framework.TestCase{
This is the unit test for the Fraction class; it declares (and possibly defines) values used by one or more tests This is the default constructor Creates a test fixture by creating and initializing objects and values Releases any system resources used by the test fixture These methods contain tests for the Fraction methods add(), toString(), etc. (note how capitalization changes)
7
publicFractionTest(){}
protectedvoidsetUp()
protectedvoidtearDown()
publicvoidtestAdd(), publicvoidtestToString(), etc.
Assert methods I
Within a test,
Call the method being tested and get the actual result assert what the correct result should be with one of the provided assert methods These steps can be repeated as many times as necessary
An assert method is a JUnit method that performs a test, and throws an AssertionFailedError if the test fails
JUnit catches these Errors and shows you the result
staticvoidassertTrue(booleantest) staticvoidassertTrue(Stringmessage,booleantest)
Throws an AssertionFailedError if the test fails The optional message is included in the Error
staticvoidassertFalse(booleantest) staticvoidassertFalse(Stringmessage,booleantest)
Throws an AssertionFailedError if the test fails
8
Example: Counter class
For the sake of example, we will create and test a trivial counter class
The constructor will create a counter and set it to zero The increment method will add one to the counter and return the new value The decrement method will subtract one from the counter and return the new value This has the advantages described earlier Depending on the JUnit tool we use, we may have to create the class first, and we may have to populate it with stubs (methods with empty bodies)
We write the test methods before we write the code
Dont be alarmed if, in this simple example, the JUnit tests are more code than the class itself
9
JUnit tests for Counter
publicclassCounterTestextendsjunit.framework.TestCase{ Countercounter1; publicCounterTest(){}//defaultconstructor protectedvoidsetUp(){//createsa(simple)testfixture counter1=newCounter(); } protectedvoidtearDown(){}//noresourcestorelease assertTrue(counter1.increment()==1); publicvoidtestIncrement(){ assertTrue(counter1.increment()==2); } publicvoidtestDecrement(){ assertTrue(counter1.decrement()==1); } }
Note that each test begins with a brand new counter This means you dont have to worry about the order in which the tests are run
10
The Counter class itself
publicclassCounter{ intcount=0; publicintincrement(){ return++count; } publicintdecrement(){ returncount; } publicintgetCount(){ returncount; } }
Is JUnit testing overkill for this little class? The Extreme Programming view is: If it isnt tested, assume it doesnt work You are not likely to have many classes this trivial in a real program, so writing JUnit tests for those few trivial classes is no big deal Often even XP programmers dont bother writing tests for simple getter methods such as getCount() We only used assertTrue in this example, but there are additional assert methods
11
Assert methods II
assertEquals(expected,actual) assertEquals(Stringmessage,expected,actual) This method is heavily overloaded: arg1 and arg2 must be both objects or both of the same primitive type For objects, uses your equals method, if you have defined it properly, as publicbooleanequals(Objecto)--otherwise it uses == assertSame(Objectexpected,Objectactual) assertSame(Stringmessage,Objectexpected,Objectactual) Asserts that two objects refer to the same object (using ==) assertNotSame(Objectexpected,Objectactual) assertNotSame(Stringmessage,Objectexpected,Objectactual) Asserts that two objects do not refer to the same object
12
Assert methods III
assertNull(Objectobject) assertNull(Stringmessage,Objectobject) Asserts that the object is null assertNotNull(Objectobject) assertNotNull(Stringmessage,Objectobject) Asserts that the object is null fail() fail(Stringmessage) Causes the test to fail and throw an AssertionFailedError Useful as a result of a complex test, when the other assert methods arent quite what you want
13
The assert statement
Earlier versions of JUnit had an assert method instead of an assertTrue method
The name had to be changed when Java 1.4 introduced the assert statement assertboolean_condition; assertboolean_condition:error_message; Both forms throw an AssertionFailedError if the boolean_condition is false The second form, with an explicit error message, is seldom necessary Use it to document a condition that you know to be true Use assert false; in code that you know cannot be reached (such as a default case in a switch statement) Do not use assert to check whether parameters have legal values, or other 14 places where throwing an Exception is more appropriate
There are two forms of the assert statement:
When to use an assert statement:
BlueJ
BlueJ 1.3.0 provides support with commands such as Create TestClass and CreateTestMethod You can create objects on the test bench and move them to the fixture (and back again) BlueJ also has a recording mode where you create and manipulate objects, and BlueJ turns your actions into test code
This is a first implementation and is still quite buggy ...