Ch 2 Exploring core JUnit This chapter covers

Ch. 2 Exploring core JUnit

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

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.

Test class and test method’s req. • The Calculator. Test program from chapter 1 defines a test class with a single test method test. Add. • 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.

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 assert. Array. Not. Equals, assert. Not-Same, assert. Not. True, 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.

JUnit assert method sample

Defenitions 1) Test class (or Test. Case 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.

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.

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.

JUnit core objects

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

Example of a parameterized test

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 @Run. With 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

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.

Cont. 4) we specify the required constructor for the test. Note that this time our test case doesn’t have a noargument 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

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: assert. Equals(2, calculator. add(1, 1), 0); sum: assert. Equals(3, calculator. add(2, 1), 0); sum: assert. Equals(4, calculator. add(3, 1), 0);

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.

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.

JUnit 4 test runners

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.

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

Cont.

Cont. • Our simple test suites Test. Suite. A and Test. Suite. B 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.

Questions?