TestFirst Development In Extreme ProgrammingXP

1
Test-First Development In Extreme Programming(XP)

• CS 562 Graduate Presentation
• By Guangyong Lu
• December 9, 2004

2
Outline

• Key message
• What is test-first
• Understanding test-first
• Why Test-First
• How to Test-First
• Statistic and Facts of using test-first

3
Key Message

• As a computer science student interests in
  software development, I suggest you to practice
  Test-First in agile software development, which
  can lead you to a better performance project. I
  believe you will love to use Test-First in agile
  software development in your second project.

4
Test-First New Building

• How risky it would be if build the house first,
  then find the building code(standards)?
  
• Constructing buildings need Test-First, then
  build(coding)
  
• As with test-first programming, a successful
  building must pass the tests set out in the
  building codes.
  

5
What is Test-First in XP?

• Once decide on next task, then write a test to
  verify successful completion of the task before
  writing the code to perform the task
  
• Test Driven Development (TDD)
• A key component of Extreme Programming(XP)
• Write test cases to verify completion of a task
  before writing code
  
• Break large coding tasks into small manageable
  pieces
  

6
Understanding Test-First

• Test must be specific, dynamic, and narrower in
  scope
  
• Concept First create a definition for a
  successful conclusion, then work toward achieving
  it.
  
• Require think differently
• Not testing first, not doing eXtreme Programming.

7
Understanding Test-First (cont.)

• Testing Cycle is short, how short?
• Be able to code a little and see the results
  quickly.
  
• Cycle through tiny steps.
• Coding more quickly and more robustly.
• A suite of unit tests is run as often as
  possible.
  
• Testing First requires you to think differently.
• Bottom-up design

SAVE
RUN TESTS
COMPILE
8
How can you test first? Theres nothing to test

• Extreme programming sidesteps the apparent
  sequential dependency of code, then test.
  
• Requires programmers think first about the
  testing and only afterwards address the actual
  code.

9
Unit Test

• Programs written to run in batches and test
  classes. Each typically sends a class a fixed
  message and verifies it returns the predicted
  answer.
• A key component of software engineering, and the
  ExtremeProgramming discipline leverages them to
  permit easy code changes.
  
• Combined into a huge suite of tests, using
  KentBeck's TestingFramework.
  
• http//c2.com/cgi/wiki?UnitTest

10
Test Case Can Be Tested

• Test case is a small piece of code that runs
  another portion of code that is yet unwritten.
  
• Test case returns true when the nonexistent code
  runs successfully, otherwise, return false.
  
• Once create the test case, then write the code
  that passes the test.(A)
  
• Maintain the order(Test, then code)

11
Writing a test case

• Determine when the subtask is successfully.
• Example

if (maxOfThreeInts(1,7,3) 7)
System.out.println(Passed Test) Else
System.out.println(Failed Test)
12
Test case example cont.

• What occurred in the example?
• Decide the method (maxOfThreeInts())
• Method takes three integers as input parameters
• Method produces one integer output
• The name of the method
• All the necessary information to write the
  signature of the method like
  

Public int maxOfThreeInts(int num1, int num2, int
num3)
13
How Can you Test-First (cont.)

• Passing the Test
• Writing method becomes the formalization of the
  algorithm to produce the output from the input
  
• Example

Public int maxOfThreeInts(int num1, int num2, int
num3) int maxnum1 if (num2 num1
num2 num3) max num2 if (num3 num1
num3 num2) max num3 return max
14
Test-First really does Mean Code Afterwards

• The technique of testing first can be so
  uncomfortable initially for programmers.
  
• The more you do test first, the easier it
  becomes.
  
• The act of writing the test case first drives the
  design
  
• Force the programmers to focus on the immediate
  subtask
  
• Eliminate ancillary issues and gives a different
  perspective on writing code
  

15
Why User Test-First?

• You will write better code
• Testing-First keeps code simplistic
• Simplicity Drives the Design
• Testing Fist Clarifies the Task at Hand
• Testing First Frees You from on-the-fly editing
• Test suites make refactoring possible
• Testing first makes sense

16
Why Use Test-First (cont.)?

• Leads to design of software
• Creates a starting point for coding
• Direct the developer to a starting point
• Test Suite is created as you develop
• Test Suite Maintenance
• Fixing broken test cases
• Adding missing tests
• Test Suite considered helpful
• The psychological benefits of green

17
Test-First VS Traditional Testing

• Test-First Development
• Source code is thoroughly unit test. Cover
  functional testing, user acceptance testing,
  system integration testing.
  
• Test fail means you have made progress.(A)
• Success if test no longer fails.
• Achieve 100 coverage test every single line of
  code is tested
  

• Traditional Testing
• Functional testing, user acceptance testing,
  system integration testing, and so on.
  
• Successful test mean find defects.
• The greater the risk profile of the system the
  more thorough your tests need to be
  
• Doesnt guarantee cover all the codes.

Ambler
18
Result

• Its fairly safe to say that Test-First results
  in significantly better code testing than do
  traditional techniques.Ambler
  
• The act of writing a unit test is more an act
  of design than of verification. It is also more
  an act of documentation than of verification.
  The act of writing a unit test closes a
  remarkable number of feedback loops, the least of
  which is the one pertaining to verification of
  function (Martin, Newkirk, and Koss 2003).

19
How to Use Test-First?

• Exhaustive testing
• Write enough test cases to handle all the
  possible scenarios
  
• Difficult and time consuming
• Representative testing
• Demonstrates the primary, expected behavior of a
  segment of code.
  
• Strive for code coverage
• Adding the tests you need.
• Follow the Testing cycle
• Key idea To cycle through tiny steps and end up
  coding more quickly.
  

20
Testing Cycle

• Testing Cycle has eight steps
• Programming team will be able to realize the
  benefits that come with test-first.
  

21
Testing Cycle 8 Steps

• Think of the next small step that you want to
  accomplish.
  
• Taking small steps that you can validate to end
  up moving quickly.
  
• Think of how you will test what you have
  accomplished this step
  
• This is white box testing.
• Complete access to the code you are testing

22
Testing Cycle 8 Steps (cont.)

• Write the code for one of your tests.
• Junit, Nunit, Xunit testing frameworks.
• Write just enough code so that your test
  compiles.
  
• Not to write the code that does everything it
  needs to do.

Testing Via Xunit Framework
23
Testing Cycle 8 Steps (cont.)

• Your test should be failing at this point.
• Simple cases of adding a constructor enable test
  to pass
  
• Now write just enough code to make your test
  pass.
  
• Only to return the result.
• Look for the next test you have to write.
• Go back to step 2 and consider whether there are
  more tests that have to be written .
  
• Now return to step(1).
• Refactor code at any point of the process if you
  need to.
  

24
Feedback of Testing Cycle

• Eight steps are straight forward to follow.
• Difficulty is not doing anymore than is
  absolutely necessary.
  
• Deciding what is the correct size step takes both
  experience and practice.

25
Guidelines for Test-First Design

• Sean Shubin provides the guidelines for test
  first
  
• The name of the test should describe the
  requirement of the code
  
• There should be at least on test for each
  requirement of the code
  
• Each possible path through the code is a
  different requirement
  
• Only write the simplest possible code to get the
  test to pass, if you know this code to be
  incomplete, write another test that demonstrates
  what else the code needs to do

26
Guidelines for Test-First Design(cont.)

• A test should be similar to sample code, it
  should be clear to someone unfamiliar with the
  code how the code is intended to be used.
  
• If a test seems too large, see if you can break
  it down into smaller tests
  
• If you seem to be writing a lot of code for one
  little test see if there are other related tests
  you could write first.
  
• Test the goal of the code, not the
  implementation.
  
• One test/code/simplify cycle at a time. Do not
  write a bunch of tests and try to get them
  working all data once

27
Guidelines for Test-first Design(cont.)

• Keep writing tests that could show if you code is
  broken
  
• Choose the simplest implementation that could
  possible work
  
• If not sure about a piece of code, add a test you
  think might break it.
  
• A test is one specific case, for which test is a
  known answer
  
• If all of the tests succeed, but the program
  doesnt work, add a test

28
Guidelines for Test-first Design(cont.)

• Tests should be as small as possible, before
  testing a requirement that depends on multiple
  things working, write a test for each thing it
  depends on.
• Tests should not take longer than a day to get
  working, typical test/code/simplify cycles take
  around 10 minutes.
  
• Dont test every single combination of inputs.
• Do not write a single line of code that doesnt
  help a failing test succeed. (A)
  
• Do not fix a bug until you have written a test
  that demonstrates the bug.
  

29
Online Examples of Test First Design

• Roman numeral converter example Rlipscombe
• http//www.differentpla.net/roger/devel/xp/test_f
  irst/
  
• Sample application that calculates bowling
  scoreRobert C. Martin and Robert S. Koss
  
• http//www.objectmentor.com/publications/xpepisode
  .htm
  

30
Fact of Test-First

• Test-First of Agile technique is not just work
  for smaller project.
  
• Big project with large amount of codes.
• Big project with large amount of testing.
• Big project with large amount of workers.

31
Proven Evidence

• Beck (2003) reports working on a Smalltalk system
  taking a completely test-driven approach which
  took 4 years and 40 person years of effort,
  resulting in 250,000 lines of functional code and
  250,000 lines of test code. There are 4000 tests
  running in under 20 minutes, with the full suite
  being run several times a day.
• Ambler worked on systems where several hundred
  person years of effort were involved.Ambler
  

32
Study

• Grigori Melnik and Frank Maurer, from Department
  of Computer Science, University of Calgary,
  studied to see what the perceptions of students
  of agile practices are and how they vary (if at
  all) depending on the programs they are enrolled
  in. Part of the questionnaires are as below

33
Study Result

• More than three-quarters of respondents
• Recognize the fact that test-first design speeds
  up the
  
• Testing process (mean3.88, SD1.00) and a
  similar
  
• Number of students believes that it improves the
• Quality of code (mean3.96, SD0.97).
• Many students mentioned that it is a matter of
  habit, and that it takes time to get accustomed
  to this highly disciplined approach. Grigori
  Melnik, Frank Maurer

34
Out Come

• Agile Test-First technique can works for both
  small size and large sized systems.
  
• More and More developers are adopting or
  considering Test-First development as an
  efficient agile technique.
  
•  

35
Conclusions

• Test-First is a development technique where you
  must first write a test that fails before you
  write new functional code
  
• Test-First is being quickly adopted by agile
  software developers for development of
  application source code
  
• Test-First defines a proven way to ensure
  effective unit testing
  
• Test-First works incredibly well in practice and
  it is something that all agile software
  developers should consider adopting.
  
• Ambler

36
Reference and Resources

• Shubin, Sean http//www.xprogramming.com/xpmag/tes
  tFirstGuidelines.htm
  
• Ambler, Scott W. http//www.agiledata.org/essays/t
  dd.html
  
• Grigori Melnik, Frank Maurer
• Introducing Agile Methods Three Years of
  Experience http//ebe.cpsc.ucalgary.ca/ebe/attach
  ?pageRoot.PublicationList2FMelnikMaurer2004c.pdf
  
• Steinberg, Daniel H, and Almer Daniel W. Extreme
  Software Engineering-A Hand-On Approach. New
  Jersey Pearson Education, Inc, 2003
  

37
Reference and Resources (cont.)

• http//c2.com/cgi/wiki?UnitTest

38
Questions ?