Back in the 1980s Ford Motor Co. had a marketing slogan: “Quality Is Job Done.”

Have you ever been in the following scenario

• finish a task, which you consider is DONE

• merge code into dev branch, send build to QA

• they come back with a problem

• you rejoice: "that an easy fix, just a null check and it's DONE"

• When organisations focus primarily on quality, defined by the following ratio:

Then quality tends to increase and costs fall over time.

• However, when organizations focus primarily on costs, costs tend to rise and quality declines over time

he taught Japan’s top management how to improve design and product quality

The Deming Philosophy, W. Edwards Deming (1900 – 1993)

• Your individual definition of DONE, has a direct impact on the overall product quality
• The values you code by everyday, have a direct impact on your team and eventually on your company

Traditional cost of change curve

Augmented traditional cost of change curve, IBM

Kent Beck's cost of change curve, with the TDD approach

Young K was working on a high school project

... by knowing about a structure which helps to "do right thing" / "build the code right"

Basic TDD rules

1. Maintain a set of automated tests
2. Only add production code once there is a test that requires that code
3. Only refactor code when all of the tests are passing
4. Never go more than a few minutes without all of the tests passing again

The TDD Cycle

Write a failing test

Watch the test fail

Write just enough code to make it pass

Watch the test pass

Fix the design (code and test)

Ensure that all tests still pass

A closer look

Minute-by-minute cycles:

Per-task cycles:

• Integrate new code and tests
• Re-run all tests in the codebase to ensure the new code does not break them
• Refactor the implementation or test code (as necessary)
• Re-run all tests in the code base 

• Write a small number of new and failing automated unit tests
• Implement the code to make the tests pass
• Re-run the new unit tests to ensure the now pass

TDD Benefits

• Increased confidence in developers working on test-driven code bases
• Increased protection from defects, especially regressions
• Better code quality (in particular, less coupling and higher cohesion)
• Tests as a replacement/supplement to other forms of documentation
• Improved maintainability and changeability of code bases
• Ability to  refactor  without fear of breaking things
• Earlier detection of misunderstandings/ambiguities in requirements
• Smaller production code bases with more simple designs
• Reduced need for manual testing
• Faster feedback loop for discovering whether an implementation is correct

In other words

• Set up a fast feedback loop (test first)
• Get frequent feedback from the running code
• Stay "check-in-able" at all times
   
• TDD is an effective discipline for working incrementally at the smallest scale
   
• Continually deliver small bits of value
  (specify, test, code, design)

String Calculator

The following is a TDD Kata- an exercise in coding, refactoring and test-first, that you should apply daily for at least 15 minutes

Before you start: 

• Try not to read ahead
• Do one task at a time. The trick is to learn to work incrementally
• Make sure you only test for correct inputs. there is no need to test for invalid inputs for this kata

1. Create a simple String calculator with a method 
int Add(string numbers) :

• The method can take 0, 1 or 2 numbers, and will return their sum (for an empty string it will return 0) for example “” or “1” or “1,2”
• Start with the simplest test case of an empty string and move to 1 and two numbers
• Remember to solve things as simply as possible so that you force yourself to write tests you did not think about
• Remember to refactor after each passing test

2. Allow the add method to handle an unknown amount of numbers

• the following input is ok:  “1\n2,3”  (will equal 6)
• the following input is NOT ok:  “1,\n” (not need to prove it - just clarifying)

4. Support different delimiters

• to change a delimiter, the beginning of the string will contain a separate line that looks like this:
  “//[delimiter]\n[numbers…]” for example
  “//;\n1;2” should return three where the default delimiter is ‘;’
   
• the first line is optional; all existing scenarios should still be supported

5. Calling add with a negative number will throw an exception “negatives not allowed” - and the negative that was passed. If there are multiple negatives, show all of them in the exception message