4. Testing

We use two kinds of testing for this repository, unit and integration testing.

Unit testing

A unit test is a test written by the programmer to verify that a relatively small piece of code is doing what it is intended to do. They are narrow in scope, they should be easy to write and execute.

Part of being a unit test is the implication that things outside the code under test are mocked or stubbed out. Unit tests shouldn't have dependencies on outside systems. They test internal consistency as opposed to proving that they play nicely with some outside system. Our unit testing is fairly straight forward, using JUnit.

This is an example of a standard unit test:

@Test
public void getAllRFIDLinksTest() {
    RFIDLink link1 = persistRFIDLink();
    RFIDLink link2 = persistRFIDLink();

    Collection<RFIDLink> links = rfidService.getAllRFIDLinks();
    assertTrue(links.contains(link1));
    assertTrue(links.contains(link2));
}

If we look at the top of this class file, we see:

public class RFIDServiceTest extends ServiceTest {

All our unit test classes extends ServiceTest. This is our unit testing helper class. It has methods that persist Entities for you. If you start testing a new entity, feel free to add a similar method there.

Integration testing

An integration test is done to demonstrate that different pieces of the system work together. Integration tests cover parts of applications, and they require much more effort to put together. They usually require resources like database instances to be allocated for them. The integration tests do a more convincing job of demonstrating the system works (especially to non-programmers) than a set of unit tests can, at least to the extent the integration test environment resembles production.

Our integration testing has a bit more of a complicated setup. We use a framework called REST Assured.

This allows for very easy testing of REST endpoints. Now we will take a look at one:

1 @Test
2 public void testGetTicketIdByRFIDAsAdmin() {
3     User admin = createAdmin();
4     Ticket ticket = createTicketForUser(admin);
5     RFIDLink link = createRfidLink(ticket);
6
7     //@formatter:off
8     given().
9         header(getXAuthTokenHeaderForUser(admin)).
10    when()
11        .get(RFID_ENDPOINT + link.getRfid() + "/ticketId").
12    then()
13        .statusCode(HttpStatus.SC_OK)
14        .body(equalTo(ticket.getId().toString()));
15    //@formatter:on
16}

Now again, at the top of the class file, we see

public class RFIDIntegrationTest extends XAuthIntegrationTest {

This is our integration testing helper class. It again has some methods that instantiate stuff. Take a look sometime.

The integration test has some things that might look strange at first glance.

• L3-5 is persisting the Entities that we are using in this test.
• L7 and L15 are comments that tell IntelliJ to not format anything in between.¹ Otherwise it would all be jumbled on one line, and this is more readable.
• L8-14 is the core REST Assured part of our integration test.
• using the given-when-then scheme,
• after given() you put any header or body that you want to give with the API call.
• after when() you put the HTTP request itself,
• after then() you put the assertions of your test.

¹To enable this, go to Settings -> Editor -> Code Style -> Check "Enable formatter markers in comments" under Formatter Control.

Now go and write some amazing tests :)