Chapter 10
Databases

Back in Chapter 6, ​When Cucumbers Go Bad​ we described the risks associated with leaky scenarios, where data left behind by one scenario affects the results of the next. In this chapter we’re going to illustrate this problem with an example, and we’ll describe the two methods for dealing with it, along with their advantages and disadvantages.

For this final installment of the worked example, we’re going to introduce a relational database into our ATM system. Almost every system you’ll write Cucumber tests for will have a database of some kind, and it helps to know how to talk to it directly from your test code. You can use ActiveRecord to connect to almost any kind of database and set up or inspect its data from your tests. We’re going to show you how to use the ActiveRecord^[45] gem to connect to existing databases from just a few lines of Ruby code.

Right now, our file-based database can only store the balance of a single customer’s account. Let’s introduce the capacity to store the balance for several different accounts, using a database table to store each customer’s account balance in a separate row.

We’ll use an sqlite3^[46] database, although the choice of database is not all that important to this example. That’s because we’ll be talking to it through ActiveRecord, which provides the same consistent interface to every relational database that it talks to.^[47] It’s a useful library for testers to know about, so we’ll start with an introduction to that library before we plug it into our example.