Teardown
Congratulations! You’ve learned a wide array of information about Test-Driven Development and how it can benefit you and your team. In this chapter, you learned a few ideas about how to keep the fire burning, both personally and within your team.
TDD is a simple cycle of specify, build, and improve. This book has provided you with a specification for how to practice TDD. You must build out your knowledge of TDD through continuing application and practice. Most importantly, you owe it to yourself and your team to continue to improve upon what this book has helped you learn.
Footnotes
| [30] |
See “Test Infected: Programmers Love Writing Tests,” http://junit.sourceforge.net/doc/testinfected/testing.htm. |
| [31] | |
| [32] |
http://biblio.gdinwiddie.com/biblio/StudiesOfTestDrivenDevelopment |
| [33] |
“Measuring the Effective of TDD on Design,” http://s3-eu-west-1.amazonaws.com/presentations2012/5_presentation.pdf |
| [34] |
http://agile2009.agilealliance.org/files/session_pdfs/ContinuousTestingEvolved.pdf |
| [35] |
See Dybå, T. et. al. “Are Two Heads Better Than One? On the Effectiveness of Pair Programming,” at http://dl.acm.org/citation.cfm?id=1309094, which summarizes a number of pair programming studies. |
| [36] |
See http://pragprog.com/magazines/2011-07/pair-programming-benefits for many other potential benefits. |
| [37] |
See http://stackoverflow.com/questions/145586/what-continuous-integration-tool-is-best-for-a-c-project. |