4. The Three Laws of TDD.
1. You are not allowed to write any production code
unless it is to make a failing unit test pass.
2. You are not allowed to write any more of a unit test
than is sufficient to fail; and compilation failures are
failures.
3. You are not allowed to write any more production
code than is sufficient to pass the one failing unit
test.
7. ● fewer than two arguments?
● more than two arguments?
● argument isn’t numeric?
8. TDD Sucks
● I never have enough time to write the tests, once I’ve
finished the main functionality.
● Testing isn’t my job, because it’s QA’s job to make sure
I do quality work
● Unit tests don’t help me, because my code works
perfectly the first time.
● I don’t like TDD, because I enjoy the hours I spend in
my debugger
● ...
9.
10. Benefits
1. Productive (Reduce your debugging time)
2. Code Quality
3. Over-engineering (YAGNI)
4. Better Interface
5. Documentation
6. Lead to more modularized, flexible, and
extensible code
11. Best Practices
1. Keep the unit small
2. Focused on only the results necessary to
validate its test.
3. Treat your test code with the same respect as
your production code.
4. Low Coupling allows each unit to be effectively
tested in isolation.
5. Mock & Stub
1. You must begin by writing a unit test for the functionality that you intend to write.
2. As soon as the unit test code fails to compile, or fails an assertion, you must stop and write production code
3. But by rule 3 you can only write the production code that makes the test compile or pass, and no more.
