1. xUnit Tests Phases
“xUnit tests follow a typical four phase sequence: setup, exercise, verify, teardown.” (Martin Flower)
According to xUnit tests, there are four phases in a test case. The first phase is the setup phase, where the SUT (System Under Test), that means the object that we want to test, and its objects collaborators are set up with values. The second phase is the exercise phase, where we must to execute the test calling a method that will use the data setup. After that, in the third phase, the test executed will be verified. Setup data on objects, executed tests and verified all of them, we gonna finish the test or teardown, which is the fourth phase.
“In the first phase, we set up the test fixture (the “before” picture) that is required for the SUT to exhibit the expected behavior as well as anything you need to put in place to be able to observe the actual outcome (such as using a Test Double (page X).) In the second phase, we interact with the SUT. In the third phase, we do whatever is necessary to determine whether the expected outcome has been obtained. In the fourth phase, we tear down the test fixture to put the world back into the state in which you found it.” (xUnit Patterns)
1.2. State Verification
“This style of testing uses state verification: which means that we determine whether the exercised method worked correctly by examining the state of the SUT and its collaborators after the method was exercised.” (Martin Flower)
State verification is a kind of style of testing that belong to Classical TDD. In this style, we have the four phases quoted above and the focus is on the final state of the objects. We setup the objects, we exercise them and after verify the state of them.
At the final of these four phases, we gonna check if an attribute has the value that it should be or if a method returns exactly what we expects, in other words, we gonna check the state.
1.3. Behaviour Verification
Behaviour Verfication is a style part of TDD Mockist, what means that this style is mock based. There are the four phases in this style too, but, as the name implies, the verify phase focus on behaviour of the SUT. We set up the objects, execute the methods which we wanna test, and after all, in verify phase, we check the behaviours.
“With state verification we do this by asserts against the warehouse’s state. Mocks use behavior verification, where we instead check to see if the order made the correct calls on the warehouse. We do this check by telling the mock what to expect during setup and asking the mock to verify itself during verification.” (Martin Flower)
As Matin Flower said, there are a few differences in the setup phase of this style if we compare to the state verification style, and it is not only in the verify phase. The set up phase has a different activity in addition to set up values, that is tell the SUT what we expect in its behaviour during the execution, and, in the verify phase the SUT will check if all our expectations were met.
“To begin with, the setup phase is very different. For a start it’s divided into two parts: data and expectations. The data part sets up the objects we are interested in working with, in that sense it’s similar to the traditional setup. (…) The second part of the setup creates expectations on the mock object.The expectations indicate which methods should be called on the mocks when the SUT is exercised.” (Martin Flower)
All of it is just possible because the Behaviour Verification is a mock-based style, part of TDD Mockist. Second Martin Flower,mocks are “objects pre-programmed with expectations which form a specification of the calls they are expected to receive”, expectations that are determined in setup phase. In a TDD Classic, without Mocks, we cannot preprogram our expectation in a SUT, because the SUT is a common object of a programing language and has not this functionality. Even it was possible, the TDD Classic doesn’t mind about behaviour, only about states.
2. Conclusion
So, we have two differences in two phases comparing this two styles. The setup phase on state verification style, we just set up values on our SUT and objects collaborators and in the verification phase we check if the state is exactly as we expects. The setup phase on behaviour verification style are divided in two phases, the first is the same as in state verification style, we set up values on SUT and objects collaborator, and the second is the difference between them, where we tell the SUT what behaviour we expect of it. The verify phase of the state verification style we call methods ou attributes to see if the final state of the SUT is correct according to execution. This phase on behaviour verification style we just ask to SUT to verify if all behaviour met our expections telled to it on setup phase.
3. References
Tássio Auad 