What is TDD, and why is it giving traditional software development practices a run for their money? This presentation answers these questions, while focusing on a popular agile methodology, Extreme Programming (XP). It places a particular emphasis on the exploratory programming nature of XP and its testing practice, TDD. The paper also summarizes prior research on TDD and includes the results from a research survey conducted to compare TDD with traditional testing practices.

1. Test-Driven Development in the
Corporate Workplace
Ahmed Owian
Linda Sherrell
STEP
Systems Testing Workshop 2010

2. Outline
• Agile Methodologies
• TDD Introduction
• Related Work
• Comparative Survey
• Conclusions and Future Work

3. Agile Methodologies
• What is Agile?
• Agile Manifesto values:
– Individuals and interactions over processes and tools
– Working software over comprehensive documentation
– Customer collaboration over contract negotiation
– Responding to change over following a plan
• eXtreme Programming (XP)
– Pair Programming
– TDD

4. What is Not TDD?
• Traditional (test-last) development
– Writing production code till done
– Testing it to verify correctness
• Waterfall
– Analysis
– Design
– Code
– Test

5. What is TDD?
• Test-Driven (test-first) development
1. Break down a task into testable units
2. Write failing automated test case in code
3. Implement production code to satisfy test
4. Refactor both test and production code
• Iterative process
– Tests drive the design for the code
– Tests and production code evolve

6. What is TDD? (cont.)
• Advantages
– Enables refactoring with confidence
– Helps find bugs as soon as introduced
• Quick iterative feedback cycle
• Side Effects
– Automated regression test suite
– Unambiguous documentation
• Usage
– Agile & Plan-driven

7. Development Process

8. Related Work
• Janzen & Saiedian (2005, 2007 & 2008)
– Tests are just icing on the cake
– TDD attracts mature programmers
– Metrics show TDD improves quality
• Sherrell, et. al. (2009)
– Experiences with XP
• Vejandla & Sherrell (2009)
– Integrating TDD into research projects

9. Related Work (cont.)
• Bhat & Nagappan (2006)
– Professional teams at Microsoft used TDD
– Produced code over twice traditional quality
– TDD added 15% more development time
– Tests continued to benefit the teams
– Served as executable documentation
• Crispin (2006)
– TDD takes effort, but is worth it

10. Comparative Survey
• Traditional Test-Last vs. TDD
• Online survey (Google spreadsheets)
– Reach many people
– Programmatically gather results
• Validity
– Respondents indicated experience
• Filtered respondents lacking experience
– Professionals from Agile Dev Conf. 2009
• Perhaps biased results

11. Summary of Responses to
“Choose the process that according to your experience…”
Summary of Responses to
"Choose the process that, according to your experience..."
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100
makes you more productive.
promotes better quality code.
produces more customer satisfaction.
results in better coverage of production code.
results in code that is easier to reuse.
results in code that is more extendable.
results in code that is easier to read and understand.
fosters better confidence in the code.
helps you to stay on schedule and meet your deadlines.
gives you a better understanding of the algorithm/logic.
better facilitates refactoring.
takes more effort.
you will be more likely to use in the future.
you like better for most tasks.
produces a product that adheres more to the requirements.
Percentages of responses
No difference
Traditional
Test-Driven 90% 100%

12. Remarkable Results
You like better for most tasks
Test-
Driven
90%
No
difference
6%
Traditional
4%
Takes more effort
Test-
Driven
38%
No
difference
35%
Traditional
27%
Fosters better confidence in the code
Test-
Driven
90%
Traditional
2%
No
difference
8%
Promotes better quality code
Test-
Driven
92%
No
difference
8%
Traditional
0%

13. Findings
• Majority found TDD more useful
• Results represented TDD favorably
• TDD takes more upfront effort
• Effort pays off later
– Code is more maintainable
– Code is easier to read and understand
– More code is actually tested
• Less time needed to fix faults

14. Summary & Conclusions
• Compared Effectiveness of TDD vs. Traditional
– Practitioners of TDD benefit from its usage
– Adhering to TDD takes discipline and skill
• This research advocates the use of TDD
– Maintainability
– Testability
– Self-documentation
– Automatic self-verification

15. Future Work
• Comparison Survey
– Collect additional responses
– Perform further analysis
• Use TDD in more applications
– Analyze the benefits over traditional

16. References
1) Beck, K., et. al. (2001). Manifesto for agile software
development. Available at: http://www.agilemanifesto.org.
Last retrieved 11/16/2009.
2) Bhat, T. & Nagappan, N. (2006). Evaluating the efficacy of test-
driven development: industrial case studies. In Proceedings of
the 2006 ACM/IEEE international Symposium on Empirical
Software Engineering (ISESE '06), pp. 356-363.
3) Boehm, B. & Turner, R. (2003). Balancing Agility and Discipline:
A Guide for the Perplexed. Addison-Wesley. Boston, MA.
4) Crispin, L. (2006). Driving software quality: how test-driven
development impacts software quality. IEEE Software, 23 (6),
pp. 70-71.
5) Janzen, D. & Saiedian, H. (2005). Test-driven development:
concepts, taxonomy, and future directions. IEEE Computer, 38
(9), pp. 43-50.
6) Janzen, D. & Saiedian, H. (2007). A leveled examination of test-
driven development acceptance. In Proceedings of the 29th
International Conference on Software Engineering, pp. 719-
722.

17. References (cont.)
7) Janzen, D. & Saiedian, H. (2008). Does test-driven development
really improve software design quality? IEEE Software, 25 (2),
pp. 77-84.
8) Jeffries, R. (2001). What is extreme programming? XP
Magazine, November 2001. Available at:
http://www.xprogramming.com/xpmag/whatisxp.htm. Last
retrieved on 11/20/2009.
9) Owian, A. & Sherrell, L. (2009). Comparison of Traditional and
Test-Driven Development. Available at:
http://spreadsheets.google.com/viewform?
hl=en&formkey=dEpub19rNWljanRlclVFQ3VsbEFObUE6MA. Last
retrieved 11/24/2009.
10) Sherrell, L., Bhagavathy, K. & Velaga, N. (2009). Experiences
with Extreme Programming. In Proceedings of World Conference
on Educational Multimedia, Hypermedia and
Telecommunications 2009 (ED-MEDIA), pp. 458-467.
11) Vejandla, P. & Sherrell, L. B. (2009). Why an AI research team
adopted XP practices. In Proceedings of the 47th ACM Annual
Southeast Regional Conference, pp. 1-4.

18. Questions?

20. Janzen & Saiedian Metrics
• J&S ascertained that TDD leads to "… simpler classes and
sometimes simpler methods" by applying the following
metrics: weighted-methods complexity, cyclomatic
complexity per method, and nested-block depth per
method.
• They also measured lines of code per method, and
methods per class discovering TDD leads to smaller
methods as well as smaller classes.
• In addition, Janzen and Saiedian measured code
coverage, and they found in most cases, TDD resulted in
more production code covered by automated tests.
• In order to measure coupling, they took the following
metrics: coupling between objects, fan-out per class,
average number of method parameters, and
information flow.