Unit testing

  • View

  • Download

Embed Size (px)


Everyone says you should test your designs, but expects you to know what that testing should be. Here we briefly look at the kinds of tests (software) engineers might encounter and what the terms being used actually mean. Finally we settle on Unit Testing as a good place to begin the testing process.

Text of Unit testing

  • 1. Unit Testing Save yourself and your project Jeslie Chermak ( [email_address] )

2. What is testing?

  • (Were going to focus on software)
  • Testing is the process of validating that software meets its design goals, behaves as expected, and can be duplicated:http://en.wikipedia.org/wiki/Software_testing
  • Note: Most of what well discuss applies equally to any other type of testing as well.

3. Testing colors

  • There really are only three:
  • http://en.wikipedia.org/wiki/Software_testing - The_box_approach
  • Black box based on no knowledge of the actual inner workings (e.g., using just the spec. or users guide).
  • White box based on detailed knowledge of the actual implementation.
  • Gray box everything in between black and white.

4. Testing levels

  • Again, basically three levels: http://en.wikipedia.org/wiki/Software_testing- Testing_levels
  • System test entire product behaves
  • Integration test one piece interacts properly with another piece
  • Unit test one piece behaves correctly in isolation

5. Testing Objectives

  • Again, basically three levels:
  • Acceptance tests confirm that things work acceptably
  • Regression tests confirm that prior problems remain resolved
  • Functional tests confirm that things behave as expected

6. Other Testing Goals

  • Security tests
  • Performance tests
  • Stability tests
  • Load tests tests
  • Usability tests
  • I18N/L10N tests
  • Destructive tests

7. Where Should I Start?

  • Begin at the beginning,
  • King, Alice in Wonderland
  • Are you building something new?
  • Are you extending something old?
  • Where ever you go, there you are
  • Buckaroo Bonzai, Buckaroo Bonzai
  • In the beginning, you test basics: you build white box, functional, unit tests.

8. Basic Principles

  • Testing can only show the presence of bugs, not their absence.
  • E. W. Dijkstra
  • Agile methodologies integrate testing as requisite part of the methodology
  • KISS

9. Some Observations

  • You can not test what you
  • dont have a definition for;
  • can not control;
  • can not measure;
  • can not access.

10. Is this correct?

  • packagecom.jcc.training.generics;
  • importjava.util.ArrayList;
  • importjava.util.List;
  • public classStack implementsjava.io.Serializable { // marker interface
  • private finalListstack=newArrayList();
  • public voidpush( finalInteger value) {
  • this . stack .add(value); // NULL allowed!
  • }
  • private Integertop() {
  • if( this . stack .isEmpty())throw newIllegalStateException();
  • return(Integer)this . stack .get( this . stack .size() - 1);
  • }
  • public Integerpop() {
  • finalInteger value =this .top();
  • this . stack .remove( this . stack .size() + 1);
  • returnvalue;
  • }
  • }

11. More Observations

  • Use a testing framework.
  • Make it a part of your IDE/process.
  • Test often, especially after a trivial change.
  • Make tests for old code before you change it.

12. Going Further

  • Wikipedia book:http://en.wikipedia.org/wiki/Book:Software_testing
  • Real world consequences:http://en.wikipedia.org/wiki/List_of_software_bugs
  • xUnit:http://en.wikipedia.org/wiki/XUnit
  • Googlesoftware testing

13. Closing thought

  • Beware of bugs in the above code; I have only proved it correct, not tried it.
  • Donald Knuth