As you start browsing the project, you realise that the application is not very complex. In fact, the project contains roughly a dozen Java classes and, as you start opening and looking at the files, you notice that none of them is longer than one hundred lines. That is pretty good, the codebase is small so you will be able to develop new features in no time.

Provided that this is a Gradle project, you quickly open the build.gradle file to acknowledge the frameworks and libraries being used within the project:

apply plugin: 'java'
apply plugin: 'org.springframework.boot'

sourceCompatibility = 1.8
targetCompatibility = 1.8

bootRepackage.executable = true

repositories {
  mavenLocal()
  mavenCentral()
}

dependencies {
  compile 'org.springframework.boot:spring-boot-starter-actuator'
  compile 'org.springframework.boot:spring-boot-starter-web'
  
  testCompile 'junit:junit:4.12'
  testCompile 'org.hamcrest:hamcrest-all:1.3'
  testCompile 'org.mockito:mockito-core:1.10.19'
}

The Gradle build field looks good. The project you are going to work on is a Spring-based web service. It uses spring-boot-starter-web, so it's very likely you will be able to run it locally without hassle. Moreover, there are some test dependencies which means there should be some tests in the test folder as well.

A couple of minutes later you already have a mental map of the application. There is a class called ThimblerigService which handles the logic of the game. It has a dependency on a RandomNumberGenerator and it only has one public method, which is placeBet. Methods and classes have an understandable name, so it isn't hard to figure out what they do:

@Service
public class ThimblerigService {
  private RandomNumberGenerator randomNumberGenerator;

  @Autowired
  ThimblerigService(RandomNumberGenerator randomNumberGenerator) {
    this.randomNumberGenerator = randomNumberGenerator;
  }

  public BetResult placeBet(int position, BigDecimal betAmount) {
    ...
  }
}

Besides that class, there is only one controller class that implements an API: it is ThimblerigAPI. It exposes only one method, which is placeBet. Other company services invoke that POST method in order to play one game in this service. The service resolves the bet and includes in the response details such as whether there's a prize won, the amount, and so forth:

@RestController
@RequestMapping("/v1/thimblerig")
public class ThimblerigAPI {
  private ThimblerigService thimblerigService;

  @Autowired
  public ThimblerigAPI(ThimblerigService thimblerigService) {
    this.thimblerigService = thimblerigService;
  }

  @ResponseBody
  @PostMapping(value = "/placeBet",
      consumes = MediaType.APPLICATION_JSON_VALUE)
  public BetReport placeBet(@RequestBody NewBet bet) {
    BetResult betResult =
        thimblerigService.placeBet(bet.getPick(), bet.getAmount());
    return new BetReport(betResult);
  }
}

This is a fairly easy setup and everything is crystal-clear, so you decide to move on and start looking at the tests.

As you open the test folder and start looking for tests, you are very surprised when you discover there is only one test class: ThimblerigServiceTest. One single good test is worth more than hundred bad ones but still, you think this application is poorly unit-tested:

public class ThimblerigServiceTest {
  @Test
  public void placingBetDoesNotAcceptPositionsLessThanOne() {
    ...
  }

  @Test
  public void placingBetDoesNotAcceptPositionsGreaterThan3() {
    ...
  }

  @Test
  public void placingBetOnlyAcceptsAmountsGreaterThanZero() {
    ...
  }

  @Test
  public void onFailedBetThePrizeIsZero() {
    ...
  }

  @Test
  public void whenThePositionIsGuessedCorrectlyThePrizeIsDoubleTheBet() {
    ...
  }
}

After opening the class and going over all the tests it contains, your impression changes slightly for the good. The tests cover the core service completely and they seem meaningful and exhaustive. But despite that, you can't avoid turning your head to John and asking him why there's only one test. He tells you they didn't have much time to create tests because they were in a hurry, so only the critical parts have tests. Whether a piece of code is critical or not is very subjective, but you understand the situation; in fact, you have been in that situations many times.

Only one second later, before you have time to go back to your task, John adds another interesting point to his answer: the quality assurance (QA) department. The aim of this department is to test all release candidates before they reach a production environment. Their mission is to find errors and bugs that might affect the application and report them. In some cases, if any of the errors found are very critical, the release is stopped and it will never be deployed to production. This procedure usually takes from three to five days. You think that could be a bottleneck in some scenarios, so you ask him to give you further details of the release process.