1. Ch. 2 Exploring core JUnit

2. This chapter covers ■ Using the core JUnit classes ■ Understanding JUnit mechanisms ■ Understanding the JUnit lifecycle

3. Objectives How do we run multiple test classes? And how do we find out which tests passed and which ones failed? In this chapter, we look at how JUnit provides the functionality to answer those questions. We begin with an overview of the core JUnit concepts—the test class, test suite, and test runner.

4. Test class and test method’s req. The CalculatorTest program from chapter 1 defines a test class with a single test method testAdd. The requirements to define a test class are that the class must be public and contain a zero-argument constructor. In our example, because we don’t define any other constructors, we don’t need to define the zero-argument constructor; Java creates it for us implicitly. The requirements to create a test method are that it must be annotated with @Test, be public, take no arguments, and return void.

5. Assert Methods Assert methods introduced in chapter 1 has two value parameters The first parameter is the expected value, and the second parameter is the actual value. JUnit provides many other methods, such as assertArrayNotEquals, assertNot-Same, assertNotTrue, and so on. It also provides the same methods with a different signature—without the message parameter. It’s a best practice to provide an error message for all your assert method calls.

6. JUnit assert method sample

7. Defenitions 1) Test class (or TestCase or test case) A class that contains one or more tests represented by methods annotated with @Test. There’s usually a one-to-one mapping between a production class and a test class.

8. 2) Suite (or test suite) A group of tests. A test suite is a convenient way to group together tests that are related. For example, if you don’t define a test suite for a test class, JUnit automatically provides a test suite that includes all tests found in the test class. A suite usually groups test classes from the same package.

9. 3) Runner (or test runner) A runner of test suites. JUnit provides various runners to execute your tests. We cover these runners later in this chapter and show you how to write your own test runners.

10. JUnit core objects

11. Running parameterized tests The Parameterized test runner allows you to run a test many times with different sets of parameters.

12. Example of a parameterized test

14. Requirements of parameterized test To run a test class with the Parameterized test runner, you must meet the following requirements. 1)The test class must carry the @RunWith annotation with the Parameterized class as its argument. 2)You must declare instance variables used in the tests 3)provide a method annotated with @Parameters The signature of this method must be public static java.util.Collection, without parameters

15. Cont. The Collection elements must be arrays of identical length. This array length must match the number of arguments of the only public constructor. In our case, each array contains three elements because the public constructor has three arguments. Our example uses this method to provide the input and expected output values for the tests. Because we want to test the add method of our Calculator program, we provide three parameters: expected value and two values that we add together.

16. Cont. 4) we specify the required constructor for the test. Note that this time our test case doesn’t have a no-argument constructor but instead has a constructor that accepts parameters for the test. 5) we finally implement the sum @Test method 6) Instantiate the Calculator program 7) Assert calls for the parameters we’ve provided

17. Running the test Running this test will loop exactly as many times as the size of the collection returned by the @Parameters method. The execution of this single test case has the same result as the execution of the following test cases with different parameters: sum: assertEquals(2, calculator.add(1, 1), 0); sum: assertEquals(3, calculator.add(2, 1), 0); sum: assertEquals(4, calculator.add(3, 1), 0);

18. JUnit test runners When you’re first writing tests, you want them to run as quickly and easily as possible. You should be able to make testing part of the development cycle: code-run-test-code There are IDEs (like Eclipse) and compilers for quickly building and running applications; JUnit lets you build and run tests.

19. Test runner overview JUnit 4 is built with backward compatibility with version 3.8.x. Because the 4.x version of JUnit is completely different from the 3.x versions, it should be possible to execute not only JUnit 4 tests but also 3.x-style tests. That’s why in its latest versions JUnit provides different runners (listed in the following table) for running JUnit 3.x tests, JUnit 4 tests, and different sets of tests.

20. JUnit 4 test runners

21. Composing a suite of test classes The next step is to run more than one test class. To facilitate this task JUnit provides the test Suite. JUnit designed the Suite to run one or more test cases. The test runner launches the Suite; which test case to run is up to the Suite. You might wonder how you managed to run the example at the end of chapter 1, when you didn’t define a Suite. To keep simple things simple, the test runne automatically creates a Suite if you don’t provide one of your own.

22. Cont. The following Listing shows how to compose multiple test classes in a single test suite.

23. Cont.

24. Our simple test suites TestSuiteA and TestSuiteB have only one test case each, a simplification to abbreviate this example. A real suite would contain more than one test class, like our master suite. You can run any of the classes in this listing as a JUnit test, one of the two test classes, one of the two test suites, or the master test suite.

25. Questions?