Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test and finally refactors the new code to acceptable standards
Red - GREEN - Repeat..
That doesn't sound fun...
Well.. It's Not..
However
When we think of it
Executable Specification
, it
changes our perspective and allows us to have
more confidence that the code we are writing corresponds to the thing we actually want to produce.
Executable Specification?
But I already have a specification document
(probably in Word written by the sales team)
excuses not to test
I'll have to write 4x more code
It was just a tiny code change
I will test it once I complete this next thing
We don't have time
Big Bang Theory is on..
Reasons to test
It will make you a better developer
It will make your code better
Tests are always there once you write them
If the tests match the specifications, you can immediately know if the code does as well.
Ariane 5...
ariane 5 Rocket
Ariane 5 Rocket
1996
10 Years of Development
40 seconds
$500 Million
64 bit TO 16 bit conversion failure
TDD - Kata
Kata (型 or 形 literally: "form"?) is a Japanese word describing detailed choreographed patterns of movements practised either solo or in pairs
The basic goal of kata is to preserve and
transmit techniques. By practicing in a
repetitive manner the learner develops the
ability to execute those techniques and
movements in a natural, reflex-like manner.
TDD - Kata
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