9 Integration testing

 

This chapter covers

  • Converting user requirements to descriptive tests
  • Writing tests that follow a behavior-driven design pattern
  • Integrating external dependencies into tests using containers

You are sitting in the conference room with your project manager, a QA lead, an Ops lead, and the CEO. The project manager stands at the front of the room and starts the presentation.

“It’s called a strangler application. The name ‘strangler application’ comes from the strangler fig tree, which builds itself around a host tree until the host tree dies. As sad as it sounds, we want to eventually sunset our old application. We feel our application has been tested enough to start rolling it out to a select group of customers. The new service will start out depending on the old service like it does today, but over time, we can gradually phase the old one out once we are satisfied that we haven’t missed anything.”

You look around the room and notice everyone nodding their heads.

“This seems to mitigate some of our risks because we can always switch back to the old service if we have any problems,” the QA lead adds.

“Exactly. We have built a system for writing flexible software that can be responsive to our needs. What are the final pieces we are missing?” your project manager adds, looking around the room.

The Ops lead chimes in, “A database with all of the translations will be needed if we want to shut down the old system.”

9.1 Phasing out the old

9.2 Behavior-driven design

9.3 Writing BDD tests in Go

9.4 Adding a database

9.5 Releasing

Summary