1. CEN 5070 Software V&V Spring 2002 Testing 102 -- Internal Modules © 2001-2002, Dr. E.L. Jones

2. 1/2002Testing 102 -- Internal Modules2 Purpose This lecture prepares the student to practice unit testing on a project by applying the concepts covered in the Software Unit Test Concepts course.

3. 1/2002Testing 102 -- Internal Modules3 Agenda Products & Deliverables Testing Classes What is Unit Testing? Testing Callable Modules Putting it All Together

4. 1/2002Testing 102 -- Internal Modules4 What is Unit Testing? Executing a software element to determine whether it meets its specification Executing a software element to discover defects or anomalies Inspecting software element code to discover defects or anomalies.

5. 1/2002Testing 102 -- Internal Modules5 What Is A Unit? Named software element with properties and behavior Separately invokable Performs single function Logically cohesive set of the above

6. 1/2002Testing 102 -- Internal Modules6 Examples of Units User-Visible software elements Fields on forms Buttons on forms Entire forms (reports) Program-Internal software elements Subprograms (procedures, functions, mains) Classes Databases

7. 1/2002Testing 102 -- Internal Modules7 Elementary Units Form Field Navigation Button Operation Button Database Field Stored Procedure Query Program Code Main Method Function Script

8. 1/2002Testing 102 -- Internal Modules8 Can A Unit Be Bigger? Yes, but beware of pitfalls Complex units are hard to test Repetition of tests more costly Tendency to focus on the easy part A composite unit (naturally related parts) A class = methods + data A form = data fields + action buttons One test script for hierarchical testing of parts, then whole

9. 1/2002Testing 102 -- Internal Modules9 Objective The practice of unit testing adds value to the development process by surfacing areas of incompleteness, inaccuracy or ambiguity. Extensive use of aids (checklists, worksheets) minimizes the effort but encourages thorough analysis.

10. 1/2002Testing 102 -- Internal Modules10 Agenda Products & Deliverables Testing Classes What is Unit Testing? Testing Callable Modules Putting It All Together

11. 1/2002Testing 102 -- Internal Modules11 Required Elements of Testing Practice S pecification for the software P rocess for designing test cases R epeatable process for designing, running and evaluating tests A ccountable artifacts of testing activities E conomical use of human, time and computing resources

12. 1/2002Testing 102 -- Internal Modules12 Recommended Practice Analysis Design Implementation Execution Evaluation Decision Table [Test Script, Driver] #Bugs Found Worksheet (Test Cases) Worksheet (Results) Specification, Code

13. 1/2002Testing 102 -- Internal Modules13 Products vs Deliverables A Product is an informal artifact from applying a testing process. belongs to the developer a physical form, not necessarily electronic A Deliverable is an artifact that attests to the application of the testing process belongs to the team an attesting signature required

14. 1/2002Testing 102 -- Internal Modules14 Product Templates Templates will be provided for these test products Black-box Schematic Decision table Unit test cases (functional, boundary) Unit test worksheets

15. 1/2002Testing 102 -- Internal Modules15 Agenda Products & Deliverables Testing Callable Subprograms/Methods What is Unit Testing? Testing Callable Modules Testing Database Procedures

16. 1/2002Testing 102 -- Internal Modules16 Testing Modules -- Overview Directly testing callable modules requires isolating the module and capturing the context in which it is called. Additional effort is required for this "code level" testing, but certain aspects can be automated, providing repeatability, efficiency and documentation.

17. 1/2002Testing 102 -- Internal Modules17 Testing Modules -- Drivers A test driver executes a unit with test case data and captures the results. Driver Test set Data External Effects Unit Arguments Results Test Set Results

18. 1/2002Testing 102 -- Internal Modules18 Implementing Test Drivers Complexity –Arguments/Results only –Special set-up required to execute unit –External effects capture/inquiry –Oracle announcing "PASS"/"FAIL" Major Benefits –Automated, repeatable test script –Documented evidence of testing –Universal design pattern

19. 1/2002Testing 102 -- Internal Modules19 Test Driver for Unit Pay Driver D_pay uses unit_environment E; { declare Hrs, Rate, expected; testcase_no = 0; open tdi_file("tdi-pay.txt"); open trs_file("trs-pay.txt"); while (more data in tdi_file) { read(tdi_file, Hrs, Rate); read(tdi_file, expected); testresult = pay(Hrs, Rate); write (trs_file, testcase_no++, Hrs, Rate, expected, testresult); }//while close tdi_file, trs_file; }//driver

20. 1/2002Testing 102 -- Internal Modules20 Test Driver Files (Pay) Test Data File File name: tdi-pay.txt Format: (test cases only) rate hours expected-pay File content: 10 40 400 10 50 550 10 0 0 ------ Note: No environment setup. Test Results File File name: trs-pay.txt Format: case# rate hours exp-pay act-pay File content: 1 10 40 400 400 2 10 50 550 500 3 10 0 0 0 ------ Note: Results file must be inspected for failures. Pass Fail Pass Test Script!!

21. 1/2002Testing 102 -- Internal Modules21 Testing Modules -- Drivers with Test Environment Set-Up The driver initializes the execution environment of the unit, and examines it after testing completes. External Effects Unit Driver Test set Data Arguments Results Test Set Results Environment Execution Environment Setup / Inquire

22. 1/2002Testing 102 -- Internal Modules22 Test Driver Files (Pay2) (Accumulates grand total of pay amounts) Pass Fail Pass Fail Test Data File File name: tdi-pay.txt Format: initial_pay_total final_pay_total {rate hours expected-pay} File content: 1000 1950 10 40 400 10 50 550 10 0 0 ------ Note: Environment setup = initialize global variable. Test Results File File name: trs-pay.txt Format: case# rate hours exp-pay act-pay env_init, env_exp, env_final File content: 1 10 40 400 400 2 10 50 550 500 3 10 0 0 0 1000 1950 1900 ------ Note: Results file must be inspected for failures. Test Script!! Initial / Expected Grand Total

23. 1/2002Testing 102 -- Internal Modules23 Test Driver for Pay2 (Accumulates grand total of pay amounts) Driver D global total_pay; { open tdi_file ("tdi-pay2.txt"); open trs_file("trs-pay2.txt"); //Set up unit_environment E read (tdi_file, initial_tot, exp_tot); total_pay = initial_tot; testcase_no = 0; while (more data in tdi_file) { read (tdi_file, Hrs, Rate); read (tdi_file, expected); testresult = pay2(Hrs, Rate); write (trs_file, testcase_no++, Hrs, Rate, expected, testresult); }//while final_tot = total_pay; write(trs_file, initial_tot, exp_tot, final_tot); close tdi_file, trs_file; }//driver

24. 1/2002Testing 102 -- Internal Modules24 Unit Test Driver Design -- Test Environment Set-Up/Inquiry Driver D uses unit_environment E; { open tdi_file (filename); open trs_file (filename); //Set up unit_environment E read (tdi_file, E_initial, E_expect); E.set (E_initial); testcase_no = 0; while (more data in tdi_file) { read (tdi_file, testdata); read (tdi_file, expected); testresult = unit(testdata); write (trs_file, testcase_no++, testdata, expected, testresult); }//while E.get(E_final); write (trs_file, E_initial, E_expect, E_final); close tdi_file, trs_file; }//driver

25. 1/2002Testing 102 -- Internal Modules25 Your Turn -- Test Driver Design Unit GenPayroll(PayDate) computes pay for all employees who submitted time records (file "time.dat") for the previous week. All employees are hourly. Employee IDs, pay rates, and YTD earnings are stored in the Employee database ("emp.db"). GenPayroll calls unit Pay (Hours, Rate) to compute gross pay. Next, GenPayroll deducts a flat 10%, then writes PayDate, EmployeeID, Hours, Rate, GrossPay, Deductions, and NetPay to the Payroll Register (file "payreg.dat"). Finally, GenPayroll updates YTD-Earning for the employee. ------------------------------- Design the test driver for GenPayroll. Focus on (1) required set- up; (2) data preparation; (3) test execution; (4) verification of results.

26. 1/2002Testing 102 -- Internal Modules26 Your Turn -- Test Driver Design Driver PayDate GenPayroll Pay Rate Hours GrossPay file "time.dat" database "emp.db" file "payreg.dat" Verification Set-Up

27. 1/2002Testing 102 -- Internal Modules27 Agenda Products & Deliverables Testing Classes What is Unit Testing? Testing Callable Modules -- DB Proc Putting It All Together

28. 1/2002Testing 102 -- Internal Modules28 Testing DB Procedures -- Overview Since the database plays a central role in a system, database procedures should be tested carefully. Automating this testing permits thorough testing and efficient verification via database queries. Trusted database code is a candidate for reuse.

29. 1/2002Testing 102 -- Internal Modules29 Testing DB Procedures -- Process Set-Up Initialize DB to baseline (or error) state Run Test Script (manual/automated) Run Verification Script (manual/auto) Verify queries, updates A test driver can combine the test and verification scripts into a single, comprehensive test.

30. 1/2002Testing 102 -- Internal Modules30 Testing Callable Units -- Summary A test driver is a reusable design pattern. Test drivers give code-level visibility into the behavior of units, while documenting the testing process. A unit driver can be used for indirect testing of lower level modules. The unit test driver can be extended to test complex units (classes).

31. 1/2002Testing 102 -- Internal Modules31 Agenda Products & Deliverables Testing Classes What is Unit Testing? Testing Callable Modules Putting It All Together

32. 1/2002Testing 102 -- Internal Modules32 Testing Classes -- Overview A class is a collection of elementary units (methods) sharing an execution context. As with forms, testing a class requires unit testing of its methods along with an "integration" test of the overall semantics of the class. The approach for unit testing is extended for classes.

33. 1/2002Testing 102 -- Internal Modules33 Testing Classes -- Drivers (Black-Box) Class Test Driver Method Args /Results Test set Data Test Set Results Class Class-state Method(s)

34. 1/2002Testing 102 -- Internal Modules34 Example -- Stack Class class Stack { public: Stack(); void push(int n); int pop(); int top(); bool empty(); private: int Size; int Top; int Values[100]; }; Notes: (1) Class state -- variables Size, Top and the first 'Size' values in array Values. (2) Methods push and pop modify class state; top and empty inquire about the state. (3) Stack does not require any test environment of its own. (4) Class state HIDDEN from test, i.e., black box.

35. 1/2002Testing 102 -- Internal Modules35 Test Driver Files (Stack class) Test Data File (tdi-stack.txt) File content: ----- 1 8 1 7 3 7 2 7 2 8 4 true ------ Note: No test environment setup. Methods: 1-push, 2-pop, 3-top, 4-empty Test Results File (trs-stack.txt) File content: ----- 1 1 8 2 1 7 3 3 7 8 4 2 7 8 5 2 8 7 6 4 1 ------ Note: Results file must be inspected for pass/fails. --- Top should be 7. --- Push. --- Pop, should be 8. --- Stack should be empty. Fail Pass

36. 1/2002Testing 102 -- Internal Modules36 Class Test Driver Design Driver dC uses class C { c = new (C); testcase_no = 0; open tdi_file("tdi_stack.txt"); open trs_file("trs_stack.txt"); while (more data in tdi_file) { op = read(tdi_file); switch (op) { case 1: //Push. read(tdi_file, value); c.push(value); write(trs_file, testcase_no, 1, value); break; case 2: //Pop. read(tdi_file, expect); value = c.pop(); write(trs_file, testcase_no, 2, expect, value); break;

37. 1/2002Testing 102 -- Internal Modules37 Class Test Driver Design … default: } //switch }//while close tdi_file, trs_file; }//class-driver case 3: //Top. read(tdi_file, expect); value = c.top(); write(trs_file, testcase_no, 3, expect, value); break; case 4: //Empty. read(tdi_file, expect); value = c.empty(); write(trs_file, testcase_no, 4, expect, value); break;

38. 1/2002Testing 102 -- Internal Modules38 Implementing Class Test Drivers Interactive vs Batch (files) Extend Unit Driver –switch to handle multiple methods –Method-specific test cases –Method interactions tested –All results stored in common results file Major Benefits -- comprehensive driver –Automated, repeatable, documented –Minimized set-up

39. 1/2002Testing 102 -- Internal Modules39 Class Test Driver -- Summary Data Driven -- flexible, extensible Varying levels of detail –black-box (method calls, no class state) –clear-box (class state, advanced topic) –global effects (test environment) A driver is a reusable pattern for testing.

40. 1/2002Testing 102 -- Internal Modules40 Clear-Box Class Testing -- Drivers Use Internal State External Test Env Class Test Driver Method Args /Results Test set Data Test Set Results Setup / Inquire Internal Test Env Class Test Env Class-state Method(s) Class State Setup/Inquire

41. 1/2002Testing 102 -- Internal Modules41 Example -- Stack Class class Stack { public: Stack(); void push(int n); int pop(); int top(); bool empty(); void SetState(int,int,int[]); void GetState(int &,int &,int[]); private: int Size; int Top; int Values[100]; }; Notes: (1) Class state -- variables Size, Top and the first 'Size' values in array Values. (2) Methods push and pop modify class state; top and empty inquire about the state. (3) "Hooks" can be created to set and retrieve the class state. (4) Stack does not require any test environment of its own.

42. 1/2002Testing 102 -- Internal Modules42 Class Test Driver Design Driver dC uses Test_Env T; uses class C { // Set up external environment // c = new (C); testcase_no = 0; open tdi_file (filename); open trs_file (filename) case -4: //Set test env// read(tdi_file. t_env); T.setenv(t_env); break; case -3: //Get test env// T.getenv(t_env); write(trs_file, t_env); break; case -2: //Set class state// read(tdi_file, c_state); c.setstate(c_state); break;

43. 1/2002Testing 102 -- Internal Modules43 Class Test Driver Design // If the internal state of the class // must be set or checked, a (-2) // precedes case "m", and a (-1) // follows case "m". // Remaining methods … // default: } //switch }//while close tdi_file, trs_file; }//driver case -1: //Get class state. c.getstate(c_state); write(trs_file, c_state); break; case m: // test class method #m. read(tdi_file, args); read(tdi_file, expect); result = method(args); write (trs_file, testcase_no++, args, expect, result); break;

44. 1/2002Testing 102 -- Internal Modules44 Agenda Products & Deliverables Testing Classes What is Unit Testing? Testing Callable Modules Putting It All Together

45. 1/2002Testing 102 -- Internal Modules45 Putting It Together Test design is the central thing Test scripts define the sequence of test actions -- a repeatable process Test drivers automate test scripts and produce test documentation Automation is reusable!

46. 1/2002Testing 102 -- Internal Modules46 CONCLUSION Unit testing lays the foundation for software testing. The techniques covered in this class extend from simple to complex units and, as we will see, to integration testing. Worksheets and templates facilitate the process while guiding the tester through a systematic design process.

47. 1/2002Testing 102 -- Internal Modules47 SOLUTIONS TO EXERCISES

48. 1/2002Testing 102 -- Internal Modules48 Unit Test Driver Design -- Global Pre/Post Conditions (pattern) Driver D uses unit_environment E; { open testdata_file(filename); open testresults_file(filename); // Set up unit_environment E\ read (testdata_file, E_initial); E.set (E_initial ); testcase_no = 0; while (more data in testdata_file) { read(testdata_file, testdata); read(testdata_file, expected); testresult = unit(testdata); write (testresults_file, testcase_no++, testdata, expected, testresult); }//while E.get(E_final); write(testresults_file, E_initial, E_expect, E_final) close testdata_file, testresults_file; }//driver