JUnit

1. JUnit

2. Why is testing good? • Due to psychological factors, programmers are bad testers. • A computer can test much faster than a human • Philosophy: “If it aren't broken, don’t fix it” • Refactoring, XP • Spartanization

3. What is unit testing? • Unit Testing – test a single element of the • system. • Unit – Class • There are other kinds of tests: • Functional Testing • Stress testing • Benchmark testing

4. Wish list: A testing framework 1. Test expressions: Means for comparing an actual result with an expected result 2. Clear indication of success/failure 3. Clear indication of failed tests 4. Split a long test method into several smaller methods 5. Continue with other tests even if a test fails 6. Continue with other tests even if a test throws an exception 7. No duplication of initialization code of tested objects 8. Side effects should not influence other tests 9. No need to maintain a list of tests

5. JUnit • JUnitis a unit testing framework for Java • http://www.junit.org • A test caseis a set of conditions to determine whether an application meets specifications. • A test suiteis a collection of test cases, test suites, or both. • A fixture is a set of objects to be tested

6. JUnit: Benefits • Writing a test is as simple as writing a method that exercises the code to be tested and defining the expected result. • JUnit gives flexibility in grouping tests and convenient ways to capture and/or summarize test failures. • The Assert class has a bunch of static convenience methods for writing test expressions. • initialize the fixture state • clean-up after a test

7. JUnit 4

8. JUnit 4.0 • To use assertion need to import org.junit.Assert.* • No need to extend from junit.framework.TestCase • No need to prefix test method with ‘test’ • Test method is annotated with @Test. • @Before method – runs before every test. • @After method – runs after every test. • @BeforeClass– runs once before first test method in its class for one-time set up. • @AfterClass– runs once after the last method in its class for one-time tear down.

9. JUnit 4.0 - Annotations • Checking for exceptions: @Test annotation can take a parameter, which declares the type of Exception that should be thrown. • @Test(expected = Exception.class) • public void nullPointerParameter() {… • The test fails if no exception is thrown. • Checking timeout: @Test annotation can take a parameter, which declares period in milliseconds. • @Test(timeout = 10) • public void nullPointerParameter() {… • The test fails if it takes more than 10 milliseconds. • Test ignorance: @Ignore annotation mean that test was ignored and not run.

10. JUnit: Running • Textual runner: • Called explicitly by user • org.junit.runner.JUnitCore.runClasses (TestClass1.class, ...);  • IDE Support • To run several test cases: • @RunWith(Suite.class) • @Suite.SuiteClasses({ • TestClass1.class, • TestClass2.class, • … }) • public class AllCalculatorTests { • }

11. JUnit: Source Code Organization • Option 1: • Test class in same folder as subject • A single hierarchy of folders • Locality • Use a special naming scheme • E.g.: SubjectClass_Test • Option 2: • Keep tests in the mirrored directory structure of source location • A duplicated hierarchy of folders • Easy to find all tests • Easy to separate source code from its tests

12. JUnit: Black Box vs. White Box • Black Box: Write tests against the interface of the subject • No need to change tests when implementation is changed. • Exponential explosion of the testing space • Practically non-feasible • White Box: Rely on implementation knowledge when writing tests • If implementation is changed need to remember to examine the test • Practical: dramatically slices the testing space

13. Practices: Test Class • A test class must have a no-arguments constructor • Use @Before and @After and not the constructor • In a suite, shorter tests should be placed first • Avoid side effects • Testing code should be simpler than subject code

14. Practices: General • Testing is meant to improve the quality of the code • Don’t change a private method into a public one so you can test it • Keeping old test running is just as important as making new ones run • Run tests as often as possible • The earlier you detect the bug the sooner you solve it • When you work on a bug, write a test case first • => Your work is done when the test case succeeds • When you change the subject class, add tests