1. REFACTORING & SOFTWARE TESTING

2. Refactoring  Refactoring is the process of altering source code so as to leave its existing functionality unchanged.  The simplest example of refactoring is renaming  The name of variable including a class or package name is changed  When the name is changed, all references to it except for comments are automatically changed at the same time.

3. Refactoring - Promote Attribute to Class class Automabile { int mileage; … }  The integer variable mileage for used automobiles is more involved than a single int variable  Therefore it can be considered «Promote Attribute to Class « refactoring class Mileage { int nomMilvalue=0; //shown on odometer int engMilvalue=0; //best estimate, accounting for replacement ….. public int compute EffectiveMileage() // to obtain estimate { ….} class Automabile { Mileage mileage; …… }

4. Refactoring Computer – Assisted  Some refactoring is computer assisted  This takes the form a wizard that interacts with the programmer  All interactive development environments are equipped with several refactoring wizards. To use Rename in Eclipse, one can place the cursor on the variable (name) and press Shift/Alt/R. New name is name_

5. Using a Refactoring Wizard Shift/Alt/R 5

6. Fowler’s Refactoring Taxonomy  Big Refactorings (Fowler describes the refactoring at the class level and have more of an architectural impact)  Composing Methods  Moving Features Between Objects  Organizing Data  Dealing With Generalization  Simplifying Conditional Expressions  Making Method Calls Simpler 6

7. Big Refactoring Example I (Fowler’s Taxonomy)  Employee SoftwareEmpClericalEmp FulltimeSoftwareEmp Employee SoftwareEmpClericalEmp Status Fulltime Retired RetiredSoftwareEmp ParttimeMaintceEmp ParttimeSoftwareEmp FulltimeMaintceEmp RetiredMaintceEmp ParttimeMaintceEmp FulltimeClericalEmp RetiredClericalEmp ParttimeClericalEmp before after 7

8. Big Refactorings (Fowler’s Taxonomy) Example II : Convert Procedural Design to Objects  Control startGame() displayCharacter() moveCharacter() VideoGame GameCharacter VideoGame start() GameCharacter display() move() before after When an object is required to control, single call to a method is required in an appropriate object Minimal control may still be needed outside of the classes

9. Big Refactoring Example III: Separate Domain from Presentation  Account name balance … displayStandard() displayHTML() Account name balance … StandardAccountGUI display () HTMLAccountGUI display () before after  GUI code occurs in the same class as the computational algorithms or the data repository.  For example The Account class my perform the computations, and also produce displays

10. Big Refactorings (Fowler’s Taxonomy) Example IV: Extract Hierarchy  Project SoftwareEngineeringProject CustomerEntertainmentProject MobileApplication DesktopApplication before after © 2010 John Wiley & Sons Ltd.

11. Software Test is a validation process  Executing code from the application is provided with input and the resulting output is compared with the required output.  Testing establishes the presence of defects but not their absence  Testing Early and Often means the Agile Connection

12. 12 Testing: Four Main Questions Testing requires significant time to decide what to test, when to do so, and with what data.  At which level conducting the testing? – Unit – Integration – System  How to choose inputs? – using the specifications/use cases/requirements – using the code  How to identify the expected output? – Test the predictions (oracles)  How good test cases are? – When we can stop the testing activity

13. 13 Test Phases  Acceptance Testing – This checks if the overall system is functioning as required.  Unit testing – This is basically testing of a single function, procedure, class.  Integration testing – This checks that units tested in isolation work properly when put togehter.  System testing –The emphasis is to ensure that the whole system can cope with real data, monitor system performance, test the system’s error handling and recovery routines.  Regression Testing  Regression Testing – This checks that the system preserves its functionality after maintenance and/or evolution tasks.

14.  Suppose that C is a body of already-tested code in an application A.  Suppose that A has been altered with new or changed code N.  If C is known to depend on N Perform regression testing on C  If C is reliably known to be completely independent of N There is no need to regression test C  Otherwise Regression test C Regression Testing: What to Retest A snjfgkjfdkgjkfdjgkfdj kgjdfkbvjfdkjbkfdjbk fdjbkjdfklbjdflkbjkldf jbkfdjblkjfdklbjfdklbj klfdjbkldfjbkljdfkbljf dklbjoikhkgkjkDHVD ABFDSGKJGFJTIURjs kjgls,al40rgnsj2340 2- hhjk ghjhgj ghjkklj;ljko fghjhjgfj g;b,kdfgjfjfjg kfdjk N dfkbljfdklHVDABFDS DHVDABFDSlkgt GKJGIURjskjgl C 14

15. What are Software Testing Types ?  Black box testing : You don't need to know the internal design in detail or have a good knowledge about the code for this test.  It's mainly based on functionality and specifications, requirements.  White box testing : This test is based on detailed knowledge of the internal design and code.  Tests are performed for specific code statements and coding styles.

16. Black- & White-box Testing Black box … requirements Actual output compared with required output White box Input determined by... Result …design elements Validation of expected behavior 16

17. Black-Box Testing  Black-Box Testing does not take the manner in which the application was designed or implemented Example: Person «a» rents « the Matrix» on May5 Person «b» rents «Gone with the Wind» on May 6 Person «a» returns «the Matrix» on May 10  This is analogous to building an automobile and then testing it by driving it under various conditions.

18. White-Box Testing  White -box tests are based on design and implementation  If the car is built with a new design for its automatic transmission, we would be wise to use this knowledge  White box testing is required

19. Unit Testing versus Post-Unit testing Reliable? Reliable part? Reliable? 19  Software applications consist of numerous parts.  Therefore the soundness of the whole depends on the soundness of the parts  Because of the dependence, we test software parts thoroughly before assembling them  A process is called as unit testing

20. Types of Post-Unit Testing  Interface testing Validates functions exposed by modules  Integration …… combinations of modules  System whole application  Usability user satisfaction  Regression changes did not create defects in existing code  Acceptance customer agreement that contract satisfied  Installation works as specified once installed on required platform  Robustness ability to handle anomalies  Performance fast enough; uses acceptable amount of memory 20

21. Post-Unit Testing Unit ….. Unit ….. Module Application on test bed Application on final platform Build ….. integration testing Interface testing system testing usability testing installation testing acceptance testing Regression testing throughout 21 Each of post-unit testing activities is performed during the process of building an application

22. Decide How and Where to get Test Input  Standard test stock market data for a brokerage application  Standard test chemical reactions for a chemical engineering application  Standard FDA procedures for the pharmaceutical industry  Standard test inputs for a compiler  Output from previous version of the application

23. Plan for Testing  Define “units” vs. non-units for testing  Determine what types of testing will be performed  Determine extent  do not just “test until time expires”  prioritize, so that important tests definitely performed  Document  individual’s personal document set included?  how / when to incorporate all types of testing?  how / when to incorporate in formal documents?  how / when to use tools / test utilities?  Determine input sources  Decide who will test  individual engineer responsible for some (units)?  how / when inspected by Qality Assurance?  how / when designed & performed by third parties?  Estimate resources  use historical data if available  Identify metrics to be collected  Define, gather, use  e.g., time, defect count, type, and source 23

24. Stopping Criteria for Testing  When tester has not been able to find another defect in 5 minutes of testing  When all nominal, boundary and out-of-bounds test examples show no defect  When a given checklist of test types has been completed  After completing a series of targeted coverage (e.g., branch coverage for unit testing)  When testing runs out of its scheduled time 24

25. 25  Unit Tests are tests written by the developers to test functionality as they write it.  Each unit test typically tests only a single class, or a small cluster of classes.  Unit tests are typically written using a unit testing framework, such as JUnit (automatic unit tests).  Target errors not found by Unit testing: - Requirements are misinterpreted by developer. - Modules don’t integrate with each other Unit Testing

26.  Both white box and black box methods are utilized during unit testing  White box unit tests focus on  the internal code structure,  testing each program statement,  every decision point and each independent path  Black box methods focus on testing the unit without using its internal structure  Equivalence partitioning and boundary value analysis

27. 27 + system increment Prioritized functionalities Write acceptance tests Execute acceptance tests Write and execute unit tests “At different points in the process” “Executed after the development”“Written before” Iterative Software Development

28. 28 The motivation of unit testing is finding faults.The motivation of acceptance testing is demonstrating working functionalities. Written and executed during the development.Written before the development and executed after. Written using a unit testing framework. Written using an acceptance testing framework (also unit testing framework). Starting point: new capability (to add a new module/function or class/method). Starting point: User stories, User needs, Use Cases, Textual Requirements, … Used to find faults in individual modules or units (individual programs, functions, procedures, web pages, menus, classes, …) of source code. Used for documentation (low level) Used to verify that the implementation is complete and correct. Used for Integration, System, and regression testing. Used to indicate the progress in the development phase. (Usually as %). Used as a contract. Used for documentation (high level) (extreme programming) When unit tests pass, write another test that fails. (extreme programming) When acceptance tests pass, stop coding. The job is done. Written by developers.Written by Customer and Analyst. Unit TestsAcceptance Tests Acceptance Testing versus Unit Testing

29. Unit Test Methods  White-Box Methods  Statement coverage Test cases cause every line of code to be executed  Branch coverage Test cases cause every decision point to execute  Path coverage Test cases cause every independent code path to be executed  Black-Box Methods  Equivalence partitioning Divide input values into equivalent groups  Boundary Value Analysis Test at boundary conditions 29