Section 22.3. ActionFixture in General

22.3. ActionFixture in General

For each row of the table, the text in the first cell is one of the following actions:

• start

  Treat the text in the second cell as a class name.

  Create an object of that class, called the actor, which is used in subsequent actions, until another start.

  However, if the class does not exist or is not a subclass of fit.Fixture, throw an exception.

• enter

  Take the text in the second cell as the name of a method, such as E.

  Find the corresponding method in the current actor with one parameter, such as public void E(T t).

  Determine T, the type of the single parameter of method E.

  Convert the text in the third cell into a value of type T.

  Call the method E with that value.

  However, if the method does not exist or cannot be called or the cell contents can't be converted to a value of type T, throw an exception.

• press

  The text in the second cell names a method, such as P.

  Find the corresponding method in the current actor with no parameter, such as public void P().

  Call the method P.

  However, if the method does not exist or cannot be called, throw an exception.

• check

  The text in the second cell names a method, such as C.

  Find the corresponding method in the current actor with no parameter but that returns a value, such as public T C().

  Determine T, the return type of the check method.

  Take the text in the third cell and convert it to an expected value of type T.

  Call the method C and compare the result with the expected value. If it matches, mark the third cell with green. If not, mark that cell with red and the actual value returned by the method.

  However, if the method does not exist or cannot be called or the result cell contents can't be converted to a value of type T, tHRow an exception.

• Otherwise, an exception is thrown.

We summarize the way that actions are mapped to methods in the actor in Figure 22.6, in which the cells marked with t must contain a value of the type T for the corresponding actor method.

Figure 22.6. Methods Corresponding to Each of the Actions

Questions & Answers

Q1:	Why does the actor have to be a subclass of fit.Fixture?
A1:	As we'll see in Chapter 25, that's so that extra information can be given for parsing values of user-defined classes in table cells.
Q2:	Why do you say "current" actor?
A2:	It's possible to dynamically switch the actor of an ActionFixture table.
Q3:	What happens when the system under test uses a database?
A3:	As we'll see in Chapter 33, we have to either: (1) set the (test) database to a known state before running each test or (2) have the system under test not use the database during testing but something else. Either way, the system under test has to be configured with testing in mind. Luckily, that has other valuable consequences when we build systems with testing support right from the start. Again, this is an important topic that we will carefully take up later.
Q4:	Won't the database slow down the tests?
A4:	Yes, that's why we avoid using a database during much of the testing. Yep, that sounds weird, but we hope to convince you otherwiselater, in Chapter 33.