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 JUnit is a unit testing framework for Java http://www.junit.org A test case is a set of conditions to determine whether an application meets specifications. A test suite is 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