Introduction to Unit Testing SE 2 Tutorial
Herman Lee May 26, 2008
Based on tutorial slides prepared by Thiago Bartolomei SE 3 lecture slides prepared by Paulo Alencar
Testing Stages
Unit testing
Testing of individual components
Integration testing
Testing to expose problems arising from the combination of components
System testing
Testing the complete system prior to delivery
Acceptance testing
Testing by users to check that the system satisfies requirements. Sometimes called alpha testing
Approaches to Low Level Testing
Debugging/Output calls
Cannot be automated Time consuming Application and test code get tangled (output calls)
Unit testing
Set of test cases targeting a single module and organized in test suites Strongly encouraged by the agile community
More Reasons to do Unit Testing
Provide a working specification of the functional code Automation
Write test once, use many times Regression tests incorrect changes discovered immediately more confidence in the code
Test Driven Design (TDD)
TDD = Test First Development + Refactoring
Test First Development
The act of writing a unit test is more an act of design than of verification. It is also more an act of documentation than of verification. (Robert C. Martin) Idea is to write first the unit tests for a module, and then implement the module. Why?
Writing the test makes you understand better the functional code and thus design it better (from the client perspective) Test becomes a documentation artifact, that clearly states the intention of the module
Test Driven Design Steps
Write tests that fail Implement modules to make tests pass Run all tests to make sure nothing is broken Refactor to keep code clean Continue development
Unit Testing with JUnit
Unit testing framework from Kent Beck (XP) and Erich Gamma (Gang of Four) Tool to support one of XP best practices Integrated in the Eclipse IDE Followed by cppUnit, phpUnit, pyUnit, etc
Preparing Eclipse Project
Create a regular project Project properties
Build Path add JUnit as a library (already shipped with Eclipse) Build Path optionally add a folder for tests Compiler if JUnit version 4, use Java version 5
That's it!
Example 1 Test Case (JUnit 3)
1) Test class must subclass TestCase. Usually it is named by adding suffix Test to tested class name. 2) Test methods must have prefix test 3) assertTrue(), assertEquals(), etc, give test pass conditions. E.g. assertTrue(x==10); 4) Test fixture a common environment to run a set of similar tests. Use setUp() and tearDown() methods to create and destroy the environment
Example 2 Test Suite (JUnit 3)
1) Test cases are organized in suites by subclassing (or constructing) TestSuite 2) Add single tests (methods) to suite using the add method or let JUnit extract them from the whole test case class 3) Execute tests using a test runner (in command line, standalone application or integrated in Eclipse)
JUnit 4
Test Cases
No longer have to extend TestCase Test methods annotated with @org.junit.Test setUp/tearDown annotated with @Before/@After Assertions statically accessed from Assert
Test Suites
No longer extend TestSuite Annotated with RunWith and Suite
Example
Source: http://www.devx.com/Java/Article/31983/0/page/1
JUnit 3 vs. JUnit 4
Source: http://www.devx.com/Java/Article/31983/0/page/2
DEMO in Eclipse
Some problems you may encounter
How to test a class A that depends on class B, if B has not been implemented yet?
Use a fake class B, called a Mock class Remember that classes should depend on interfaces B should be an interface! Note how this forces you to think about and minimize the dependencies, in order to make testing easier!
Some problems you may encounter
How to test a class that is very big and participates in many scenarios?
Rethink why this class is so big (God Class = Bad Smell) Refactor it in several smaller classes with well defined functionality and test them individually.
Some problems you may encounter
Where do I put my tests?
Either in the same package as the tested class:
pack.TheClass, pack.TheClassTest
Or in a test package:
pack.TheClass, pack.test.TheClassTest
Also, in an Eclipse project, you can have different source folders with the same package:
src/pack.TheClass, test/pack.TheClassTest Advantage you have protected access to the class
Some problems you may encounter
How to test UI?
Test functionality by accessing directly the lower tier (maybe a Facade or MVC pattern?) Testing UI itself usually requires specific tool support - Ex. HTTPUnit to do webpages testing
References / Further Study
Test Driven Development (TDD)
Test Driven Development: By Example, by Kent Beck http://www.agiledata.org/essays/tdd.html
Agile Software Development, Refactoring, Test First Design
Agile Software Development: Principles, Patterns, and Practices, by Robert C. Martin Refactoring: Improving Design of Existing Code, by Martin Fowler http://www.xprogramming.com and .org
References / Further Study
Unit test design patterns
http://www.marcclifton.com/tabid/87/Default.aspx http://www-106.ibm.com/developerworks/library/jmocktest.html
JUnit
http://www.junit.org JUnit 3 vs 4
http://www.devx.com/Java/Article/31983
