Prototype

1
Test-Driven Development
Presented By Christopher Higginbotham Course
CSCI 577b Date 25 April 2007
2
What is Test-Driven Development?

• Test driven development (TDD) is a key practice
  in XP.
• It is the process of writing test cases for code,
  before writing the code.
• The process is iterative, a developer will cycle
  back and forth between the test cases and their
  code with each change that is made.
• TDD produces loosely coupled, highly cohesive
  systems.

3
Origins of Test Driven Development

• Extreme Programming is obsessed with feedback,
  and in software development, good feedback
  requires good testing.
• The automated unit tests are all collected
  together, and every time any programmer releases
  any code to the repository, every single one of
  the unit tests must run correctly 100 of the
  time
• This gives programmers immediate feedback on the
  status of the software.

4
Reasons for Test-Driven Development

• A TDD approach integrates automated tests into
  the requirements and analysis phases of a
  project, resulting in higher-quality applications
  and more expeditious integration and deployment
  cycles.
• Traditional testing activities are expensive due
  to how late they occur in the development
  process.
• It forces a developer to think through the design
  of the code before writing it, thereby specifying
  it in detail.
• TDD allows developers to be much more flexible
  towards our requirements volatility.

5
Focus of Test-Driven Development

• Each test treats the object/class being tested
  like a black box.
• Encourages the design to be performed from the
  clients point of view, where the test acts as the
  user.
• Forces software engineer on understanding
  interface design issues such as
• Parameters
• Return values
• Behavior
• Object lifetime

6
How to successfully implement Test-Driven
Development

• Simple Creation
• Easily write tests for new code that we create
• Automatically add new tests to the
  regression-test repository at the same time as
  new code is added to the code base.
• Definitive Pass/Fail Criteria
• Quickly view the results of the automated
  regression-test run, both on a development
  machine and on the build server.
• Push Button Repeatability
• Quickly run those test and the entire
  regression-test locally on a development machine
  before adding new code to the code base
• Automatically and quickly run the entire
  regression-test suite against a new build of the
  code base
• Receive automatic notification if their new code
  has broken any tests in the regression-test
  suite

7
Steps to implement Test-Driven Development
TDD software engineers develop production code
through rapid iterations of the following

• Create a small number of automated unit test
  case(s).
• Run the new unit test case(s) to ensure they
  fail.
• Implement the code that should cause the new unit
  test cases to pass.
• Run the new unit test cases to ensure they now
  pass with the new code.
• Refactoring the code as needed.
• Repeat the cycle.

8
Tasks Test Driven Development Does Not Solve

• Reusable Assets
• They do not come with a test suite.
• User Interfaces
• There are testing tools that exist, but they are
  typically difficult to use.
• Agile teams leave GUI testing as a manual
  process.
• Database Regression
• Currently not supported well by automated tools
• Legacy Systems
• Systems were not developed using TDD, so there
  are no required tests.

9
Benefits of Test Driven Development

• By moving testing earlier in the development
  process, it is possible to reduce cost while
  realizing benefits from increased testing
  activity.
• Instead of being in the position where we had
  spent a lot of waterfall time developing a
  product or feature, where the cost of change is
  very high, we find ourselves in the enviable
  position whereby we can demonstrate parts of the
  product or feature much earlier.

10
Conclusion

• TDD helps produce loosely coupled systems by
  forcing software engineers to focus their
  understanding on interface design.
• TDD generates automated unit tests against
  developed source that must pass at 100 prior to
  being released to the source repository.
• Moving testing earlier in the development process
  should reduce cost by reducing the risk of
  defects being discovered during a traditional
  system testing phase.

11
Questions
12
References

• David Janzen , Hossein Saiedian, Test-Driven
  Development Concepts, Taxonomy, and Future
  Direction, Computer, v.38 n.9, p.43-50, 2005
• Jeff Patton, Hitting the target adding
  interaction design to agile software development,
  OOPSLA 2002 Practitioners Reports, p.1-ff, 2002
• C. Dudley Girard, Tom Briggs, Tools and
  techniques for test-driven learning in CS1,
  Journal of Computing Sciences in Colleges, Volume
  22 , Issue 3, p.37-43, 2007
• Ivana Turnu, Marco Melis, Alessandra Cau,
  Michele Marchesi, Alessio Setzu, Introducing TDD
  on a free libre open source software project a
  simulation experiment, Proceedings of the 2004
  workshop on Quantitative techniques for software
  agile process, p.59-65, 2004
• Karen Keefe, Judithe Sheard, Martin Dick,
  Adopting XP Practices for Teaching Object
  Oriented Programming, Conferences in Research in
  Practice in Information Technology, Vol. 52.,
  2006

13
References continued

• Jacques Philippe SAUVÉ, Osório Lopes ABATH Neto,
  Walfredo CIRNE, EasyAccept A Tool to Easily
  Create, Run and Drive Development with Automated
  Acceptance Tests, AST06, May 23, 2006
• Matthias M. Muller, Frank Padberg, On the
  Economic Evaluation of XP Projects, ESEC/FSE03,
  September 15, 2003
• Christopher G. Jones, TEST-DRIVEN DEVELOPMENT
  GOES TO SCHOOL, Consortium for Computing Sciences
  in Colleges, p.220-231, 2004
• Steve Freeman, Tim Mackinnon, Nat Pryce, Joe
  Walnes, Mock Roles, Not Objects, p.236-246,
  OOPSLA04, Oct. 2428, 2004
• Thirumalesh Bhat, Nachiappan Nagappan, Evaluating
  the Efficacy of Test-Driven Development
  Industrial Case Studies, ISESE'06, September
  2122, p.356-363, 2006
• Gerardo Canfora, Aniello Cimitile, Felix Garcia,
  Mario Piattini, Corrado Aaron Visaggio,
  Evaluating Advantages of Test Driven Development
  a Controlled Experiment with Professionals,
  ISESE'06, September 21-22, p.364.371, 2006

14
References continued

• E. Michael Maximilien, Laurie Williams, Assessing
  Test-Driven Development at IBM, Proceedings of
  the 25th International Conference on Software
  Engineering, p.564-569, 2003
• Jaime Spacco, William Pugh, Helping Students
  Appreciate Test-Driven Development (TDD),
  OOPSLA06 October 2226, p.907-913, 2006
• Boby George, Laurie Williams, An Initial
  Investigation of Test Driven Development in
  Industry, Proceedings of the 2003 ACM symposium
  on Applied computing, p.1135-1139, 2003
• Scott W. Ambler, Dr. Dobb's Dr. Dobb's Agile
  Newsletter, http//www.ddj.com/dept/debug/18940046
  9?cidAmbysoft, June 12, 2006
• Craig Murphy, Improving Application Quality Using
  Test-Driven Development (TDD), Software
  Development Articles Programming, Testing,
  Project, UML, Agile, Tools, Open Source, Web,
  http//www.methodsandtools.com/archive/archive.php
  ?id20, 2005

15
References continued

• Paulo Caroli, Using JMock with Test Driven
  Development, Enterprise Java Community Using
  JMock in Test Driven Development,
  http//www.theserverside.com/tt/articles/article.t
  ss?lJMockTestDrivenDev, December, 2006
• Ron Jeffries, What is Extreme Programming?,
  http//www.xprogramming.com/xpmag/whatisxp.htm,
  November, 2001