It's a shame that the functional requirements, which were neatly stated in the spec, weren't preserved in the test code. Rather than "arrange", "act", "assert"

It's a shame that the functional requirements, which were neatly stated in the spec, weren't preserved in the test code. Rather than "arrange", "act", "assert", I've taken to writing the Gherkin spec inline with the test code, e.g. @Test public void onlyExistingEmailsCanResetTheirPasswords() { //Given an email address which is not in the database String email = "unknown@example.com"; when(userRepository.findByEmailAddress("unknown@example.com")) .thenReturn(null); //When a password reset is requested for that email UserServiceImpl userService = ... userService.startResetPasswordProcess("unknown@example.com"); //Then no password reset notification should be sent verify(notificationService, never()).sendResetPasswordNotification(any()); //And the user should be given a success message so they can't determine if the email address is already present verify(userInterface, once()).sendMessage("You have been sent Please check your email."); } This way you preserve the intent for the programmers that will come after you, but you don't need a complicated Gherkin runner