Guidance Cards - Code

From School of CS Student Wiki
Revision as of 16:24, 25 July 2014 by gravatar Mbax9mb5 [userPHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs) (Code Card 2)
Jump to navigation Jump to search

Part of Red-Green-Go!
Good collection of testing anti-patterns

Code Card 1

Requires Review/Re-wording

Take the simplest route to making the current suite of tests pass.
Code 1.jpg

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 | QR Code

Code Card 2

Requires Review/Re-wording

Use if-statements in the production code to allow several hard-coded results to be returned, satisfying several tests.
Code 2.jpg
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. | QR Code

Code Card 3

Requires Review/Re-wording

"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."
Code 3.jpg
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) | QR Code


Requires Review/Re-wording

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.

recompiling consideration


Requires Review/Re-wording

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.


  • gravatar Mbasssme [userPHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] ·
  • gravatar Mbax9mb5 [userPHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+]