Guidance Cards - Test
Test Card 1
Carefully written TDD Test Suites provide confidence in the code supporting the system functionality and also help us understand the subtleties of more complex problems. Kent Beck describe this as "Managing Fear" ( fear in the sense of this-is-a-hard-problem-and-I-can’t-see-the-end-from-the-beginning ).
In order to get most of TDD we aim to write as many tests as possible to describe a certain piece of functionality thus uncovering more details about it and reducing conceptual complexity.
A good example of the application of this is the FizzBuzz application. By writing multiple tests for both the "Fizz" and "Buzz" cases we discover a simplistic and elegant solution for the "FizzBuzz" case (instead of handling "FizzBuzz" as a separate functional piece it is being treated as a combination of "Fizz" and "Buzz" cases).
If we consider an alternative test case arrangement - first tackling the "FizzBuzz" case and later the individual "Fizz" and "Buzz" Cases, it would have been much harder to outline the solution.
Test Card 2
Why choosing the happy path is sensible place to start + simple example <br/ Happy paths tend to be the shortest path - straight down the middle of the functional graph. The simplest smallest vertical slice of functionality
The first agile principle: "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."
One of the best ways to maximise business value early in the development is to focus on delivering all the major functionality. This approach is called "happy path" scenario.
Also known as the "sunny day" scenario, the happy path is the "normal" path of execution through a use case or through the software that implements it. Nothing goes wrong, nothing out of the normal happens, and we swiftly and directly achieve the user's or caller's goal.
Test Card 3