Chapter 5. Mocks, Stubs, Test Spies

verified. But in fact this is not the case here. Another possibility is that we are testing very "defensively". This means we are trying to protect ourselves from bad things which are really outside the scope of the original requirements. Testing whether the SUT does not make something is often questionable. In our case, there is no direct requirement that clients who are not subscribed should not receive the message; however, I find it logical to add this one, and in my opinion such a test is legitimate. But this is a subjective matter, and you might well hold a different view here.

Now I spend some time looking at the test code. I see some kind of a pattern there. The consecutive tests verify what happens when there are one, two or no clients subscribed to the SUT. I have made this pattern more visible by rearranging the order of the tests, as displayed in Listing 5.30 (for the sake of brevity, only method signatures are shown).

Listing 5.30. Refactored tests: order changed

public class RaceResultsServiceTestBeforeCombining {

//zero subscribers @Test

public void notSubscribedClientShouldNotReceiveMessage() { ... }

//one subscriber

@Test

public void subscribedClientShouldReceiveMessage() { ... }

// two subscribers @Test

public void allSubscribedClientsShouldReceiveMessages() { ... }

}

I like the new version better. It shows how things are progressing. Good.

5.4.4. The Fourth Test: Subscribe More Than Once

Let us now verify the behaviour of the RaceResultsService when subscribers subscribe more than one time. This situation is a little bit outside of the "path of normal, reasonable usage (happy path)" of the SUT; however, it is possible, and should be tested.

Listing 5.31 shows a test which verifies that a subscriber who subscribes again still receives only one message (only the new test method is shown, for the sake of simplicity – the rest of the test class has not changed).

Listing 5.31. The fourth test: subscribed client subscribes again

@Test

public void shouldSendOnlyOneMessageToMultiSubscriber() { raceResults.addSubscriber(clientA); raceResults.addSubscriber(clientA); raceResults.send(message);

verify(clientA).receive(message);

}

By default, Mockito verifies that the method has been invoked exactly once.

After running the test, it transpires that our implementation is not behaving as expected (Listing 5.32).

85