Software Testing, JUnit


Published on

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Software Testing, JUnit

  1. 1. Unit Testing and the J-Unit Framework CS4320 Fall 2003
  2. 2. Two Key Concepts <ul><li>Validation: Are we building the right thing? Conformance to customer requirements and quality attributes. </li></ul><ul><li>Verification: Are we building the thing right? Process conformance, quality activities. </li></ul>
  3. 3. Where does testing fit in? PHASE O: Testing == Debugging PHASE 1: Testing shows the software works PHASE 2: Testing shows the software doesn’t work PHASE 3: Testing doesn’t prove anything, it reduces risk of unacceptable software delivery. PHASE 4: Testing is not an act, a mental discipline of quality.
  4. 4. “ The ” Testing Quote Testing cannot show the absence of defects, it can only show that software defects are present. We cannot test quality into a product, we have to design it in.
  5. 5. Test Objectives <ul><li>Tests intended to find errors </li></ul><ul><li>Good test cases have high p for finding a yet undiscovered error </li></ul><ul><li>Successful tests cause program failure, i.e. find an undiscovered error. </li></ul><ul><li>Minimal set of test cases needs to be developed because exhaustive testing not possible </li></ul>
  6. 6. Testing Phases <ul><li>Unit </li></ul><ul><li>Integration </li></ul><ul><li>Component </li></ul><ul><li>System </li></ul><ul><li>Usability </li></ul><ul><li>Regression </li></ul><ul><li>Validation </li></ul><ul><li>Alpha/Beta (FUT/OT) </li></ul>
  7. 7. Types of testing <ul><li>Structural (Whitebox) </li></ul><ul><li>Functional (Blackbox) </li></ul><ul><li>Statistical (Random) </li></ul><ul><li>Mutation </li></ul><ul><li>Object Oriented (State-based) </li></ul><ul><li>Insert latest PhD thesis topic here </li></ul>
  8. 8. Whitebox Testing <ul><li>AKA Structural, Basis Path Test </li></ul><ul><li>Normally used at unit level </li></ul><ul><li>Assumes errors at unit level are in the control structure or data path </li></ul><ul><li>Generates test cases to test control paths through the code </li></ul><ul><li>Criteria includes Control-Flow and Data-Flow based coverage </li></ul>
  9. 9. Coverage Criteria <ul><li>Control Flow based: </li></ul><ul><ul><li>Statement Coverage (All nodes) </li></ul></ul><ul><ul><li>Branch (or Decision) Coverage (All edges) </li></ul></ul><ul><ul><li>All Paths </li></ul></ul><ul><li>Data Flow based: </li></ul><ul><ul><li>All DU paths </li></ul></ul><ul><ul><li>All C uses </li></ul></ul><ul><ul><li>All Defs </li></ul></ul><ul><ul><li>Etc… </li></ul></ul>
  10. 10. Example Program int invoice (int x, int y) { int d1, d2, s; if (x<=30) d2=100; else d2=90; s=5*x + 10 *y; if (s<=200) d1=100; else if (s<=1000) d1 = 95; else d1 = 80; return (s*d1*d2/10000); } if d2=100 d2=90 if d1=100 if d1=95 d1=80 return x>30 s>200 s>1000
  11. 11. Strength of Coverage All Paths All du Paths All u All c some p All d All p some c All p Branch Statement
  12. 12. How effective? Strategy Mean Cases Bugs Found Random Testing 100 79.5 Branch Testing 34 85.5 All Uses 84 90.0
  13. 13. Blackbox Testing <ul><li>AKA Specification-Based </li></ul><ul><li>Uses functional requirements to derive test cases </li></ul><ul><li>Assumes errors include missing or improperly implemented functions </li></ul><ul><li>No knowledge of implementation details </li></ul>F(x) x Result
  14. 14. Equivalence Partitioning <ul><li>Divide input domain into classes of data </li></ul><ul><li>Single test case can cover all “equivalent” data elements </li></ul><ul><li>Partitions consist of valid and invalid sets </li></ul>
  15. 15. Invoice Specification Invoices are calculated using the following algorithm based on quantity of x and y: Item X sells for $5 and Item Y sells for $10 Invoice Total >=$200 get 5% discount Invoice Total >=$1000 get 10% discount Invoices that order more than 30 X items get a 5% discount
  16. 16. Border/Boundary Conditions Most errors happen at the boundary, so select test cases that test at and on each side of the boundary. X Boundaries: 30, 31, -1, 0 Y Boundaries: -1, 0 Invoice Total Boundaries: 200, 199, 999,1000 If there are specification limits on data sizes be sure to test at the limits i.e. program must store up to 100 numbers, then test at 100. What happens at 101???
  17. 17. What is xUnit? <ul><li>An automated unit test framework </li></ul><ul><li>Provides the Driver for unit(s) </li></ul><ul><li>Provides automatic test runs </li></ul><ul><li>Provides automatic result checks </li></ul><ul><li>Available for multiple languages: </li></ul><ul><ul><li>cppUnit </li></ul></ul><ul><ul><li>sUnit </li></ul></ul><ul><ul><li>Junit </li></ul></ul><ul><ul><li>… </li></ul></ul>
  18. 18. Junit Terms <ul><li>Failure: Expected </li></ul><ul><li>Error: Unexpected (Exception) </li></ul><ul><li>TestCase: Collection of method tests </li></ul><ul><li>Test Fixture: Object Reuse for multiple tests </li></ul><ul><li>TestSuite: Collection of Test Cases </li></ul><ul><li>TestRunner: Interface </li></ul><ul><ul><li>awt, swing,text </li></ul></ul>
  19. 19. Example, Complex Class public class Complex { int real_part; int imaginary_part; public Complex(int r, int i) { real_part=r; imaginary_part=i; } public Complex() { real_part=0; imaginary_part=0; } public boolean Equal(Complex c) { boolean result = false; if ((real_part==c.get_r()) && (imaginary_part==c.get_i())) result=true; return result; } public Complex Add(Complex c) { Complex result = new Complex(c.get_r()+real_part,c.get_i()+imaginary_part); return result; } public int get_r() { return real_part;} public int get_i() { return imaginary_part; } }
  20. 20. Using Junit (Create Fixture) <ul><li>public class ComplexTest extends TestCase { </li></ul><ul><li>Complex c1; </li></ul><ul><li>Complex c2; </li></ul><ul><li>protected void setUp() { </li></ul><ul><li>c1 = new Complex(7,3); </li></ul><ul><li>c2 = new Complex(12,6); </li></ul><ul><li>} </li></ul><ul><li>protected void tearDown(){ </li></ul><ul><li>} </li></ul><ul><li>} </li></ul>
  21. 21. Using Junit (Add Test Cases) <ul><li>public void testAdd() { </li></ul><ul><li>Complex result = c1.Add(new Complex(5,3)); </li></ul><ul><li>assertEquals(result.get_r(),c2.get_r()); </li></ul><ul><li>assertEquals(result.get_i(),c2.get_i()); </li></ul><ul><li>} </li></ul><ul><li>public void testEqual(){ </li></ul><ul><li>assertTrue(!c2.Equal(c1)); </li></ul><ul><li>assertTrue(c1.Equal(new Complex(7,3))); </li></ul><ul><li>} </li></ul>assertNull, assertNotNull, assertSame
  22. 22. Using Junit (Make Suite) <ul><li>public static Test suite() { </li></ul><ul><li>TestSuite suite = new TestSuite(); </li></ul><ul><li>suite.addTest(new ComplexTest(“testAdd”)); </li></ul><ul><li>suite.addTest(new ComplexTest(“testEqual”)); </li></ul><ul><li>return suite; </li></ul><ul><li>} </li></ul>
  23. 23. Using Junit (Batch Invoke and Constructor) <ul><li>public static void main(String[] args) { </li></ul><ul><li>; </li></ul><ul><li>} </li></ul><ul><li>public ComplexTest(String s) { </li></ul><ul><li>super(s); </li></ul><ul><li>} </li></ul>
  24. 24. The Graphical UI
  25. 25. UI on Failure
  26. 26. What Junit does not do: <ul><li>Figure out your tests for you </li></ul><ul><li>Calculate any coverage criteria </li></ul><ul><li>Test GUI’s </li></ul><ul><ul><li>Except extensions: </li></ul></ul><ul><ul><ul><li>JFCUnit </li></ul></ul></ul><ul><ul><ul><li>Jemmy </li></ul></ul></ul><ul><ul><ul><li>Pounder </li></ul></ul></ul><ul><ul><ul><li>Abbot </li></ul></ul></ul>
  27. 27. Administrative <ul><li>Download latest version (3.8.1) from: </li></ul><ul><li> </li></ul><ul><li>Setup classpath to junit.jar </li></ul><ul><li>Include appropriate ui in main </li></ul><ul><li>Import junit.framework.* </li></ul>
  28. 28. Next Time <ul><li>Extreme Programming!!! </li></ul>