Execution And Verification Are Tightly Coupled

Test cases are composed of three primary sections:

  • Cache initial state. The primary task for any test case is verifying that an action had the intended effect; if the test case is to know what changed it clearly must save off the starting state.
  • Execution. The test case must do something to have something to verify.
  • Verification. The test case uses the cached starting state and its knowledge about what it did to verify that the current state matches the test case’s expectations. This is perhaps the most important part of the test case, since it doesn’t matter how many hoops a test case sends the application through if the results are not accurately and thoroughly verified.

Using this strategy, knowledge of what test actions are to be executed become paramount to effective verification, so execution and verification each become tightly tied to the other. Indeed, a typical test case has this verification hard-coded within itself. This gives the test case everything it needs to execute; this also binds everything needed to understand or review the test case into the test case itself. However, the tight correlation between execution of the test case and verification of the test case makes reuse of either the execution steps or the verification nearly impossible. Additionally, any changes in the actions the test case executes generally require modifying the verification as well.

We have developed a technique that enables test case verification to be driven by actions being executed yet still be decoupled from the details of test case execution.

Comments (4)

  1. Tom says:

    Quite a cliff-hanger…!

  2. In many of my posts I have alluded to the automation stack my team is building, but I have not provided…

  3. I’ve recently been reading an article about how to de-couple the various sections of a test case.  I love the idea of being able to write test usable test cases from the very onset of a feature. This framework seems very flexible and usable but for me the

  4. In many of my posts I have alluded to the automation stack my team is building, but I have not provided…

Skip to main content