9 Writing solid automated acceptance tests

 

This chapter covers

  • The importance of writing high-quality automated tests
  • Patterns for implementing reliable and sustainable tests

In the next few chapters, we’ll look at turning the automated scenarios we discussed in the previous chapters into fully automated acceptance tests for different types of applications and technologies. Before we dive into the technical details, we need to look at the bigger picture. We need to consider how to ensure that, no matter what technology or combination of technologies we use, the quality of our tests remains high.

A good acceptance test communicates its intent clearly and provides meaningful feedback about the current state of the application. It is reliable and easy to maintain so that the value provided by the test outweighs the cost of maintaining it.

But when automated acceptance tests are poorly designed, they add to the maintenance overhead, costing more to update and fix when new features are added than they contribute in value to the project. A large number of test automation initiatives fail or become ineffective for this very reason, so it’s important to design your acceptance tests well. In this chapter, we’ll look at a number of techniques and patterns that can help you write automated acceptance tests that are meaningful, reliable, and maintainable. Let’s start by discussing what makes an industrial-strength acceptance test.

9.1 Writing industrial-strength acceptance tests

9.2 Using personas and known entities

9.2.1 Working with persona in your scenarios

9.2.2 Storing persona data in HOCON

9.3 Layers of abstraction

9.3.1 The Business Rules layer describes the expected outcomes

9.3.2 The Business Flow layer describes the user’s journey

9.3.3 Business tasks interact with the application or with other tasks

9.3.4 The Technical layer interacts with the system

Summary