Your SlideShare is downloading. ×
0
Testing, The Ugly Stepchild of
Software Development

  Better Living through Software
              Testing
    Chris Berr...
Why Test?
   It’s easy to fool yourself.
   Increase confidence.
   Increase productivity.
   Increase courage.
   It...
Test Early, Test Often
   Defects are order of magnitude cheaper
    to fix when programmers find their own
    errors.
...
Preemptive Testing
   The Art of catching bugs before they
    happen.
   Defensive Programming.
   Programming by Cont...
The Assertion
   The hallmark of Defensive
    Programming.
   Allows you to assert that a particular
    condition is m...
Sanity Checking
   A simple coding convention which
    requires all Classes to provide a boolean
    isSane method.
   ...
Logging/Debug Prints
   Low tech debugging technique. Often
    the only way to debug threaded code.
   Can speed develo...
Unit Testing
   Test each unit of code independently.
   In OO, this equates to testing a Class
    and its public inter...
Unit Testing is Glass Box
Testing
   You Must be aware of
       All branches of the method under test.
       What inp...
Building a Good Unit Test
   Test for
       Data integrity:
       Valid input: Insure that correct outputs are
      ...
Deciding on Unit Test Input
   Equivalence Partitioning.
       Good partitioning gives rigor without
        redundancy...
Equivalence Partitioning
   An equivalence class is a definition of a
    group of inputs, any one of which
    should be...
Boundary Analysis
   The term for choosing the appropriate
    values to test a particular equivalence
    subset.
   Ch...
Dealing with Exceptions
   Catch all unplanned Exceptions.
   Match all thrown Exceptions with the
    conditions expect...
Classic Unit Test construct
Generate argument providers
Loops over all argument providers
  Construct the Object under tes...
Integration Testing
   Tests which prove that the program
    properly executes some required
    functionality.
   Typi...
eXtreme Programming
   “A lightweight, low-risk, flexible,
    predictable, and fun way to develop
    software”.
   Tak...
XP in a Nutshell
   Code is king.
   Embrace change.
   Constant design.
   Emphasis on refactoring.
The Four Variables
   Cost
   Time
   Quality
   Scope.
The Four Values of XP
   Communication
   Simplicity
   Feedback
   Courage.
Central Principles of XP
   Rapid Feedback.
   Assume Simplicity.
   Incremental change.
   Embrace change.
   Qualit...
Secondary Principles of XP
   Teach Learning.
   Small Initial Investment.
   Play to Win.
   Concrete Experiments.
 ...
Secondary Principles of XP,
continued
   Work with instincts.
   Accepted responsibility.
   Local adaptation.
   Trav...
Four Basic Activities of XP
   Coding.
   Testing.
   Listening.
   Designing.
XP Development Practices
   On-site Customer
   System Metaphor
   Pair Programming
   Tests Before Code
   Simple De...
XP Development Practices,
continued
   Merciless Refactoring
   Continuous Integration
   Collective Ownership
   Codi...
Testing the XP way
   A simplified, pragmatic, and less rigorous
    approach to testing.
   Tests things that might bre...
Summary
   The earlier you catch a bug the less it is
    going to cost you.
   Testing can actually speed up your
    d...
Acknowledgements
   Some of the Slide Notes for this presentation
    were lifted verbatim from several sources;
       ...
Resources
   www.xprogramming.com/software.htm
   www.extremeprogramming.org
   www.pragmaticprogrammer.com
BerrySandiaTestingtalk.ppt
BerrySandiaTestingtalk.ppt
Upcoming SlideShare
Loading in...5
×

BerrySandiaTestingtalk.ppt

189

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
189
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "BerrySandiaTestingtalk.ppt"

  1. 1. Testing, The Ugly Stepchild of Software Development Better Living through Software Testing Chris Berry – Feb 21, 2000 Chris Berry cberry@cyberplus.com
  2. 2. Why Test?  It’s easy to fool yourself.  Increase confidence.  Increase productivity.  Increase courage.  It simply makes programming more fun!
  3. 3. Test Early, Test Often  Defects are order of magnitude cheaper to fix when programmers find their own errors.  No communication cost.  The bug tracking system does not become involved.  The error does not block or corrupt the work of other developers.
  4. 4. Preemptive Testing  The Art of catching bugs before they happen.  Defensive Programming.  Programming by Contract.
  5. 5. The Assertion  The hallmark of Defensive Programming.  Allows you to assert that a particular condition is met, and commonly, if it is not, terminate execution.  Pre and post conditions.  Not to be confused with Exceptions.
  6. 6. Sanity Checking  A simple coding convention which requires all Classes to provide a boolean isSane method.  Used to determine whether a particular Instance is in a sane state.
  7. 7. Logging/Debug Prints  Low tech debugging technique. Often the only way to debug threaded code.  Can speed development.  Permanent artifact.  Can result in “Scroll-blindness”. Best to divert logging to a file rather than standard out.  The log4j package for Java.
  8. 8. Unit Testing  Test each unit of code independently.  In OO, this equates to testing a Class and its public interface.  Involves debugging, simultaneously, the code, the test, and the Spec.
  9. 9. Unit Testing is Glass Box Testing  You Must be aware of  All branches of the method under test.  What inputs should produce what results or Exceptions.  The interplay of affected member variables and arguments.
  10. 10. Building a Good Unit Test  Test for  Data integrity:  Valid input: Insure that correct outputs are generated for correct input conditions.  Invalid input: Insures proper error handling.
  11. 11. Deciding on Unit Test Input  Equivalence Partitioning.  Good partitioning gives rigor without redundancy.  Boundary Analysis  Things go wrong at the edges.  Expected and unexpected Exceptions.
  12. 12. Equivalence Partitioning  An equivalence class is a definition of a group of inputs, any one of which should be treated exactly the same by the method under test.  Eliminates redundant tests. The behavior of the method should be “equivalent” so only one test need be run for any equivalence class.
  13. 13. Boundary Analysis  The term for choosing the appropriate values to test a particular equivalence subset.  Choose values at the edge of the set.  Also a good idea to include the transition values.
  14. 14. Dealing with Exceptions  Catch all unplanned Exceptions.  Match all thrown Exceptions with the conditions expected to produce them.
  15. 15. Classic Unit Test construct Generate argument providers Loops over all argument providers Construct the Object under test (OUT) Optionally save the state of the OUT Call the method under test (MUT) If an exception was generated Test for unhandled exceptions Else Assertions on the resultant, OUT, and arguments End loops
  16. 16. Integration Testing  Tests which prove that the program properly executes some required functionality.  Typically involves the integration of many Classes.  Often a test from the perspective of the customer.
  17. 17. eXtreme Programming  “A lightweight, low-risk, flexible, predictable, and fun way to develop software”.  Takes commonsense best practices and applies them to an extreme degree.
  18. 18. XP in a Nutshell  Code is king.  Embrace change.  Constant design.  Emphasis on refactoring.
  19. 19. The Four Variables  Cost  Time  Quality  Scope.
  20. 20. The Four Values of XP  Communication  Simplicity  Feedback  Courage.
  21. 21. Central Principles of XP  Rapid Feedback.  Assume Simplicity.  Incremental change.  Embrace change.  Quality work.
  22. 22. Secondary Principles of XP  Teach Learning.  Small Initial Investment.  Play to Win.  Concrete Experiments.  Honest communication.
  23. 23. Secondary Principles of XP, continued  Work with instincts.  Accepted responsibility.  Local adaptation.  Travel Light.  Honest measurement.
  24. 24. Four Basic Activities of XP  Coding.  Testing.  Listening.  Designing.
  25. 25. XP Development Practices  On-site Customer  System Metaphor  Pair Programming  Tests Before Code  Simple Design
  26. 26. XP Development Practices, continued  Merciless Refactoring  Continuous Integration  Collective Ownership  Coding Standards
  27. 27. Testing the XP way  A simplified, pragmatic, and less rigorous approach to testing.  Tests things that might break. Testing simple methods, like accessors, is valueless.  Write the tests first.  Keep the tests running.  Tests are automatic. Run the full suite several times a day.  JUnit, a Java testing framework. A C++ version (CPPUnit) is now available.
  28. 28. Summary  The earlier you catch a bug the less it is going to cost you.  Testing can actually speed up your development time, and improve your quality of life.  XP is a pragmatic approach to writing better software.  XP embraces change.
  29. 29. Acknowledgements  Some of the Slide Notes for this presentation were lifted verbatim from several sources;  “Test Infected. Programmers Love Writing Tests” by Eric Gamma and Kent Beck.  “eXtreme Summary - An Overview of eXtreme Programming eXplained: Embrace Change” by Brad Appleton.  “Divide and Conquer - Preemptive and Unit Testing” by Chris Berry  “The Pragmatic Programmer” by Andrew Hunt and David Thomas.
  30. 30. Resources  www.xprogramming.com/software.htm  www.extremeprogramming.org  www.pragmaticprogrammer.com
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×