Software Testing, JUnit
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Software Testing, JUnit

on

  • 2,325 views

 

Statistics

Views

Total Views
2,325
Views on SlideShare
2,320
Embed Views
5

Actions

Likes
1
Downloads
69
Comments
0

1 Embed 5

http://www.slideshare.net 5

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Software Testing, JUnit Presentation Transcript

  • 1. Unit Testing and the J-Unit Framework CS4320 Fall 2003
  • 2. Two Key Concepts
    • Validation: Are we building the right thing? Conformance to customer requirements and quality attributes.
    • Verification: Are we building the thing right? Process conformance, quality activities.
  • 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. “ 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. Test Objectives
    • Tests intended to find errors
    • Good test cases have high p for finding a yet undiscovered error
    • Successful tests cause program failure, i.e. find an undiscovered error.
    • Minimal set of test cases needs to be developed because exhaustive testing not possible
  • 6. Testing Phases
    • Unit
    • Integration
    • Component
    • System
    • Usability
    • Regression
    • Validation
    • Alpha/Beta (FUT/OT)
  • 7. Types of testing
    • Structural (Whitebox)
    • Functional (Blackbox)
    • Statistical (Random)
    • Mutation
    • Object Oriented (State-based)
    • Insert latest PhD thesis topic here
  • 8. Whitebox Testing
    • AKA Structural, Basis Path Test
    • Normally used at unit level
    • Assumes errors at unit level are in the control structure or data path
    • Generates test cases to test control paths through the code
    • Criteria includes Control-Flow and Data-Flow based coverage
  • 9. Coverage Criteria
    • Control Flow based:
      • Statement Coverage (All nodes)
      • Branch (or Decision) Coverage (All edges)
      • All Paths
    • Data Flow based:
      • All DU paths
      • All C uses
      • All Defs
      • Etc…
  • 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. 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. How effective? Strategy Mean Cases Bugs Found Random Testing 100 79.5 Branch Testing 34 85.5 All Uses 84 90.0
  • 13. Blackbox Testing
    • AKA Specification-Based
    • Uses functional requirements to derive test cases
    • Assumes errors include missing or improperly implemented functions
    • No knowledge of implementation details
    F(x) x Result
  • 14. Equivalence Partitioning
    • Divide input domain into classes of data
    • Single test case can cover all “equivalent” data elements
    • Partitions consist of valid and invalid sets
  • 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. 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. What is xUnit?
    • An automated unit test framework
    • Provides the Driver for unit(s)
    • Provides automatic test runs
    • Provides automatic result checks
    • Available for multiple languages:
      • cppUnit
      • sUnit
      • Junit
  • 18. Junit Terms
    • Failure: Expected
    • Error: Unexpected (Exception)
    • TestCase: Collection of method tests
    • Test Fixture: Object Reuse for multiple tests
    • TestSuite: Collection of Test Cases
    • TestRunner: Interface
      • awt, swing,text
  • 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. Using Junit (Create Fixture)
    • public class ComplexTest extends TestCase {
    • Complex c1;
    • Complex c2;
    • protected void setUp() {
    • c1 = new Complex(7,3);
    • c2 = new Complex(12,6);
    • }
    • protected void tearDown(){
    • }
    • }
  • 21. Using Junit (Add Test Cases)
    • public void testAdd() {
    • Complex result = c1.Add(new Complex(5,3));
    • assertEquals(result.get_r(),c2.get_r());
    • assertEquals(result.get_i(),c2.get_i());
    • }
    • public void testEqual(){
    • assertTrue(!c2.Equal(c1));
    • assertTrue(c1.Equal(new Complex(7,3)));
    • }
    assertNull, assertNotNull, assertSame
  • 22. Using Junit (Make Suite)
    • public static Test suite() {
    • TestSuite suite = new TestSuite();
    • suite.addTest(new ComplexTest(“testAdd”));
    • suite.addTest(new ComplexTest(“testEqual”));
    • return suite;
    • }
  • 23. Using Junit (Batch Invoke and Constructor)
    • public static void main(String[] args) {
    • junit.textui.TestRunner.run(suite());
    • }
    • public ComplexTest(String s) {
    • super(s);
    • }
  • 24. The Graphical UI
  • 25. UI on Failure
  • 26. What Junit does not do:
    • Figure out your tests for you
    • Calculate any coverage criteria
    • Test GUI’s
      • Except extensions:
        • JFCUnit
        • Jemmy
        • Pounder
        • Abbot
  • 27. Administrative
    • Download latest version (3.8.1) from:
    • www.junit.org
    • Setup classpath to junit.jar
    • Include appropriate ui in main
    • Import junit.framework.*
  • 28. Next Time
    • Extreme Programming!!!