TDD

-> what (thinking about the problem, writing tests first)
-> how (Red, Green, Refactor)
Claims (presented one by one)
-> Kent Beck
-> deterrent for over-engineering
-> gives api feedback
-> can catch logic errors
-> serves as documentation
-> controls the feeling of being overwhelmed
-> helps separate implementation from interface
-> helps define and narrow the problem being solved
-> helps control anxiety with instant feeback
-> Uncle Bob Martin
-> decreased debugging times
-> improves confidence in refactoring
-> helps describe the system with examples
-> the system design is steered towards testability
-> can inform architectural decisions
-> usually keeps bug counts lower
-> Michael Feathers
-> quick feedback
-> steers design
-> helps reinforce precise thought and reflection

Research (presented one by one)
-> Assessing Test-Driven Development at IBM
-> Experiment about Test-first programming
-> A structured experiment of test-driven development
-> Using Test-Driven development in the classroom: Providing Students with Aut
omatic, Concrete Feedback on Performance
-> Driving Software Quality: How Test-Driven Development Impacts Software Qual
ity
-> Rethinking Computer Science Education from a Test-first Perspective
-> Implications of Test-Driven Development - A Pilot Study
-> Evaluation of Test-Driven Development
-> An Empirical Evaluation of the Impact of Test-Driven Development on Softwar
e Quality
-> Evaluating Advantages of Test Driven Development: a Controlled Experiment w
ith Professionals
-> A Prototype Empirical Evaluation of Test Driven Development
-> Does Test-Driven Development Really Improve Software Design Quality?
-> Realizing quality improvement through test driven development: results and
experiences of four industrial teams
-> Evaluating the Efficacy of Test-Driven Development: Industrial Case Studies
-> Test-Driven Development as a Defect-Reduction Practice
-> Factors Limiting Industrial Adoption of Test Driven Development: A Systemat
ic Review
Research conclusions:
-> Not all studies show benefits but most show it's not worst than not using T
DD
-> Not all claims above were addressed (same are more personal and difficult t
o measure)
-> Most research recognises an increased development cost when using TDD
Personal experience:
-> small projects
-> benefits are less visible
-> will give examples of when TDD did not pull its own weight
-> big projects
-> will give examples of the benefits claimed above
-> dynamic vs static
-> prototype vs product
Conclusion
-> pragmatism (when to do)
-> more research is necessary
-> some criticism is not sound
-> no other technique provides the same benefits
-> takes a lot of discipline and time to master