TDD (test-driven development) involves writing unit tests before production code according to three laws: 1) write only enough code to fail a test, 2) write only enough test to fail initially, and 3) write only enough code to pass the test. An example involves testing an add() function by ensuring it handles errors for too few/many arguments and non-numeric values. Benefits of TDD include reduced debugging time, higher code quality, avoiding over-engineering, better interfaces, documentation, and more modular code. Best practices are to keep units small and focused, treat tests as production code, and design for low coupling and isolation.

1. TDD
Andy

2. Test-driven Development
● red/green/refactor where red means fail and
green means pass.

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.

5. Example
The subroutine add() takes two
arguments and adds them together.
The result is returned.

6. Live Coding

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
● ...

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

12. Anti-Pattern
1. Avoid dependencies between test cases.
2. Do not test implementation details.
3. Avoid slow running tests.

13. Drawback
1. UI
2. Management support is essential
3. TDD is dead(?)

14. Q&A

15. Thank you

16. REFS
● http://en.wikipedia.org/wiki/Test-driven_development
● http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd
● http://googletesting.blogspot.tw/2014/04/the-real-test-driven-development.html
● http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html
● https://www.facebook.com/notes/kent-beck/rip-tdd/750840194948847
● https://github.com/nelsonic/learn-mocha
● http://martinfowler.com/articles/mocksArentStubs.html
● http://en.wikipedia.org/wiki/Mock_object
● http://googletesting.blogspot.tw/