Software Testing, JUnit

Embed Size (px)

Text of Software Testing, JUnit

  • 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 doesnt work PHASE 3:Testing doesnt prove anything, it reduces risk of unacceptable software delivery. PHASE 4:Testing is not an act, a mental disciplineof 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 highpfor 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 (x1000 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 Testing10079.5 Branch Testing3485.5 All Uses8490.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 classComplexTest 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 GUIs
    • 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!!!

Recommended

View more >