[tdd] test driven development #test, #tdd

tdd.md

TDD & BDD

• A test-case per class approach fails to capture the ethos for TDD
• adding a new class is not the trigger for writing tests

• the tigger is implementing a requirement
• test the public API only

• it is NOT be confused with the classical unit test definition of targeting a module
• we avoid file system, database, simple because these shared fixture elements prevent us running in isolation from other tests, or cause our tests to be slow.
• explicitly writing a test that target a method on a class is not a TDD developer test.
• TDD unit tests focus on a story, Use-case, scenario

Rule 1

avoid testing implementation details, test behaviors

Rule 2

avoid writing a test because of Adding a new method to a class

Rule 3

The Trigger for writting new test is implementing a requirement

Rule 4

Write tests only agianst the stable contract

Rule 5

follow these steps for TDD

• write a test
• run it to see that it is red
• make it green
• remove duplication in the implementation

Rule 6

Do not write new unit tests when refactoring to clean code

Rule 7

Test behaviors not implementations

Rule 8

Do not make everything public in order to test it.

More videos

Dev Ternity 2007: Ian Cooper TDD where did it all go wrong https://www.youtube.com/watch?v=EZ05e7EMOLM

Behavior Driven Development vs traditional development https://www.youtube.com/watch?v=JwLhR9RI3ew

• Kent Beck
• David Heinemeier
• Martin Fowler
• Dan North ( BDD)