This section provides a brief introduction to the internals of Zorro, which might help you understand the analysis and classification techniques a bit better.
Zorro recognizes TDD using Software Development Stream Analysis (SDSA), a framework to study low-level software processes. Hackystat, SDSA and Zorro together provide a three-layer software architecture for recognition of TDD. This architecture is illustrated in Figure 7.7, “ Three layer architecture of Hackystat, SDSA and Zorro ”.
Zorro episodes are intended to reflect the iterative development manner of Extreme Programming (XP). In an XP iteration, developers focus on one task only, which is also called a story. It should not take more than an hour or two to complete a story and a developer should start a new story only after the previous story is finished. An XP story may result in at least one but potentially several Zorro episodes.
Zorro divides the development stream into episodes using a "test-pass tokenizer", which starts a new episode after a successful unit test invocation. Figure 7.8, “ The Test-Pass Tokenizer ” illustrates how the test-pass tokenizer splits development stream into test-pass episodes.
It is important to understand the relationship between Zorro episodes and the "red/green/yellow" stop light development pattern. First of all, in the red/green/yellow pattern, the "yellow", or refactoring stage is optional. In other words, not all red/green sequences will result in the need for refactoring. Thus, a valid TDD sequence might be red, green, red, green, red, green, yellow, red, green, yellow, red, green. Because the red/green sequence is mandatory in TDD but red/green/yellow is optional, Zorro episodes partition development into red/green episodes and "stand-alone" yellow episodes. This makes recognition somewhat simpler and more reliable.
Development is driven by automated unit tests in Test-Driven Development. The test-pass tokenizer divides the set of development events captured by the Hackystat sensor into episodes that end with successful unit tests.
All Test-Driven episodes must start with test creation. Let's revisit the 5 steps of TDD style software development.
Quickly add a test
Run all tests and see the new one fail
Make a little change
Run all tests and see them all succeed
Refactor to remove duplication
A test-pass episode is test-driven if it matches steps 1 through 4. The "yellow light", or refactoring step is separated into its own episode. Figure 7.9, “ Test-Driven Episode Inference Rules ” illustrates the logical sequence of development activities in a test-driven episode.
Type 1, or (TDD, 1) is a complete test-driven episode including the complete sequence of writing the test case, having the system fail to compile as a result, getting the system to compile but having the test case fail to execute, and finally getting the test case to pass. Types 2, 3, and 4, or (TDD, 2), (TDD, 3), and (TDD, 4) are TDD episodes in which one of these intermediate stages does not occur. For example, you might write a test case but not have the system fail to compile as a result. This would be an example of (TDD, 3).