Guidance Cards - Code
Code Card 1
The key benefit of TDD is the ability to specify system behaviour by tests, and parallel to that - assert it by the same tests. This notion allows us to create concrete measures of failure, thus making the whole development process more measurable and predictable.
A good way to understand this notion is to imagine the TDD as a 'conversation' between the developer and the system, where tests are the concrete pieces of information and are direct result from the conversation.
To explain this in more detail I will borrow a small part of the FizzBuzz example. Let's assume that you are the developer and I am the system, you can ask me deterministic concrete questions about myself that I can answer in one word or with yes or no. For example, you may ask me - "What would you return if I gave you 2 as an input" and I would answer "(String) 2", from this you can write the test shouldConvertTwoToItselfAsString(). Another example - you ask me "What would you return if I gave you 3 as an input?", I would answer "Fizz". This second example specifies another test - shouldConvertThreeToFizz(). Again, this gives as concrete information about the system as well as a concrete measure of failure - functions work only if the tests pass. Of course this 'conversation' is simply the thought process each developer goes through before writing a test.
Quickly getting the bar to go to green dominates everything else. If a clean, simple solution is obvious, then type it in. If the clean, simple solution is obvious but it will take a minute, then make a note of it and get back to the main problem, which is getting the bar green is seconds. This shift in aesthetics is hard for some experienced software engineers. They only know how to follow the rules of good engineering. Quick green excuses all sins. But only for a moment. (Kent Beck, TDD by Example)
Reveals omissions in existing test suite
Explain the idea of test as specification. If you want to get more information ask more questions
Link to YAGNI + Animation example?, code example
Explain how paterns are revealed by evolutionary design with example
Code Card 2
"When the tests ask for specific result, the simplest way to make them pass is to return that hard-coded result."
Introduce triangulation and triangulation discussion source, asks people to _suspend their belief for a bit_. Link to YAGNI? Maybe the TAX example? Concrete example
!Notate explicit connection / overlap between different cards
Fake It (‘Til You Make It) What is your first implementation once you have a broken test? Return a constant. Once you have the test running, gradually transform the constant into an expression using variables.
Code Card 3
"When you have hard-coded the return of an expected test result, and you add a new test, the simplest way to make the test pass is to use a conditional statement (if statement) to return the required result."
Similarly to the above example, faking the decision making aspect (the conditional statement) of your code, will make the test pass. Once you have the test running, gradually transform the constants and the static conditional statements into expressions.
Rolling example showing the evolutionary approach and what happens when you can hardcode a number opf diff values for related tests.
Floating if-statement, for triangulating the first test of a function group (if IV do specific thing, else do general thing)
When writing code work in steps that get you back to compiling code as soon as possible.
Definitely need a concrete example - code change that requires several steps. Breaks it down in compiling steps.
• This applies to refactoring as well
We will make mistakes. If you leave a long gap between writing code and compiling you may lose your progress. Compiling code means you can run the tests. Code which does not compile has no degree of confidence in the changes made since the last compile.
When writing code work in steps that get you back to passing test suites as soon as possible. This also applies to refactoring. We want to minimise the ammount of code changes between passing states of the codes so we can find errors quickly. Project that shows all the red crosses along the project structure appears as we type new code.