Test Driven Development (TDD) is a technique where tests are written before code to define desired functionality, with the cycle of writing a test, seeing it fail, then writing code to pass the test while refactoring code for quality. TDD ensures requirements are met, forces clean code principles like isolated and decoupled components, and leads to improved test coverage and faster debugging. For effective TDD, tests should be clean, self-documented, have single asserts, run fast, be independent, and have boolean outputs. While it may initially slow development time, TDD provides long term benefits.

1. TDD
Test Driven Development

3. TDD:
 is a technique for building software that guides software development by writing
tests

4. Uncle Bob Laws:
It is a cycle we have to iterate over. We write a test on something that we want to
implement such that when the test is run, the result will be “fail” then we write an
implementation that is just enough so that the test pass. We then fix our code
quality which we may have overlooked since we were focusing on making the
test pass without making the test fail.
Write Test
Write Code
Refactor

5. Benefits of TDD:
1. TDD ensures that your system actually meets requirements defined for it.
2. It serves clean code principles:
a. The code should be simple
b. tests force you to test components in isolation from each other, and from I/O.
Given some input, the unit under test should produce some known
output. (decoupling)
c. It force you to separate UI from logic using design patterns and good
architecture.
3. Testing first leads to improved test coverage, because we write test before
writing logic. It eliminates the fear of merge.
4. Tests serve as a documentation.
5. Faster debugging.

6. To have good TDD
 Tests should be clean so that they always encourage me to use them.
 Tests should be self documented.
 Tests should have only one assert.
 Tests should be fast.
 Tests should be independent.
 Tests should have Boolean output

7. TDD slows development time?