• Start with the system model
• The system contains the SUT (system under test)
• The SUT does not exist in isolation, it interacts with other participating objects in the system model that are not yet implemented: collaborators
• The test model is derived from the SUT
• To be able to interact with collaborators, we add objects to the test model
• These are called test doubles (substitutes for the collaborators during testing)

Taxonomy of test doubles

• Dummy: often used to fill parameter lists, passed around but never actually used
• Fake: a working implementation that contains a “shortcut” which makes it not suitable for production code
  • Example: a database stored in memory instead of on a disk
• Stub: provides canned answers (e.g. always the same) to calls made during the test
  • Example: random number generator that always return 3.14
• Mock: mimic the behavior of the real object and know how to deal with a specific sequence of calls they are expected to receive

Motivation for mock objects

• There is a system model for an auction system with 2 types of policies

• We want to unit test Auction, which is the SUT

• The mock object test pattern is based on the idea to replace the interaction with the collaborators in the system model, that is Person, BiddingPolicy and TimingPolicy, by mock objects

• These mock objects are created at startup time

• A mock object replaces the behavior of a real object called the collaborator and returns hard-coded values

• A mock object can be created at startup time with the factory pattern

• Mock objects can be used for testing the state of individual objects and the interaction between objects

• The use of mock objects is based on the record play metaphor

EasyMock

• Open source testing framework for Java

• Uses annotations for test subjects (=SUT) and mocks

  @TestSubject
  private ClassUnderTest classUnderTest = new ClassUnderTest();
  
  @Mock
  private Collaborator mock;
  

• Specification of the behavior

  expect(mock.invoke(parameter)).andReturn(42);
  

• Make the mock ready to play

  replay(mock);
  

• Make sure the mock has actually been called in the test (additional assertion)

  verify(mock);
  

@ExtendWith(EasyMockExtension.class)
class EnrollmentServiceTest {

	@TestSubject // Instantiate the SUT
	private EnrollmentService enrollmentService = new EnrollmentService();
	
	@Mock // Create the mock object
	private Course courseMock;
	
	@Test
	void testEnrollStudentSuccessful() {

		Student student = new Student();
		int expectedSize = student.getCourses().size() + 1; // Specify the expected behavior
		expect(courseMock.enroll(student)).andReturn(true);
		
		replay(courseMock); // Make the mock object ready to play
		
		enrollmentService.enroll(student, courseMock); // Execute the SUT
		
		assertEquals(expectedSize, student.getCourses().size()); // Validate observed against expected behavior
		verify(courseMock); //Verify that enroll() was invoked on courseMock once
		}
}

Best practices for testing

• Use prefixes actual* and expected*
• Use fixed data instead of randomized data
• Write small and specific tests: do not extend tests to “just one more tiny thing”
• Insert test data right in the test method
• Favor composition over inheritance
• Dumb tests are great: compare the output with hard coded values: do not reuse or rewrite production logic
• Focus on testing a complete functional requirement (vertical slide)
• Use constructor injection if possible
• Separate asynchronous execution and actual logic
• Use parameterized tests
• Mock remote services (e.g. using Spring MockMvc)