In this chapter
- speeding up slow test suites by running faster tests first
- using the test pyramid to identify the most effective ratio of unit to integration to system tests
- using test coverage measurement to get to and maintain the appropriate ratio
- getting a faster signal from slow tests by using parallel and sharded execution
- understanding when parallel and sharded execution are viable and how to use them
In the preceding chapter, you learned how to deal with test suites that aren’t giving a good signal—but what about tests that are just plain old slow? No matter how good the signal is, if it takes too long to get it, it’ll slow down your whole development process! Let’s see what you can do with even the most hopelessly slow suites.
Remember Cat Picture Website from chapter 2? Its biggest competitor, Dog Picture Website, has been struggling with its velocity. Jada, the product manager, is upset because it’s taking months for even the simple features that users are demanding to make it to production.
To understand why development is so slow for Dog Picture Website, let’s take a quick look at the architecture and pipeline. You might notice that the Dog Picture Website architecture is a bit less complex than some of the other architectures we’ve looked at: the engineers have separated their frontend and backend services, but they haven’t gone any further than that, and they haven’t moved any of their storage to the cloud.
