Why TDD ?

Pictorial shows four possible scenarios. This is not a time trend, as scenarios are independent, and we can place 'either / or' between them.

- Most commonly an engineer writes code and then executes a test to verify this code. This corresponds to scenario # 4. The problem with this option is that the validity of the test is not ascertained.

- Considering carefully each scenario, one can conclude that scenario # 1 is the only logical and effective option.

- If test fails before code is added, it speaks for goodness of test. Scenario # 3 speaks for the faulty code.

- In option # 2, test pass before code is added, which speaks for a faulty test.

Here is a great post explaining TDD - github.com/dwyl/learn-tdd

- Do not change code, unless get a failing test

- An immediate goal of TDD is to provide “intentional coverage”. This test must cover this “intent” of this piece of code.

- A fundamental advantage of TDD that it divides code into small chunks, which is at the heart of incremental delivery.

‍