,
Improve The Test Case Design of Object OrientedSoftware by Refactoring
DIVYA PRAKASH SHRIVASTAVA
Department of Computer ScienceAl Jabal Al Garbi UniversityZawya, LIBYA
R.C.JAIN
Department of Computer ApplicationSamrat Ashoka Technological InstituteVidisha, INDIA
Abstract
—This Refactoring is the process of changing a softwaresystem aimed at organizing the design of source code, makingthe system easier to change and less error-prone, whilepreserving observable behavior. This concept has becomepopular in Agile software methodologies, such as eXtremeProgramming (XP), which maintains source code as the onlyrelevant software artifact. Although refactoring was originallyconceived to deal with source code changes.Two key aspects of eXtreme Programming (XP) are unittesting and merciless refactoring. We found that refactoring testcode is different from refactoring production code in two ways:(1) there is a distinct set of bad smells involved, and (2)improving test code involves additional test code refactorings. wedescribe a set of code smells indicating trouble in test code and acollection of test code refactorings explaining how to overcomesome of these problems through a simple program modification.
Keywords- Test Smell, Test Case, Refactoring, Unit Testing,Object Oriented, TDD.
I.
I
NTRODUCTION
(H
EADING
1)
Computer software is an engine of growth of social-economy development which requires new techniques andstrategies. The demand for quality in software applications hasgrown. Hence testing becomes one of the essential componentsof software development which is the indicator of quality [4].“Testing proves the presence, not the absence of bugs”-- E.W.DijkstraThe unit test provides the lowest level of testing duringsoftware development, where the individual units of softwareare tested in isolation from other parts of program/softwaresystem. Automated Testing is the other program that runs theprogram being tested, feeding it with proper input, and thuschecking the output against the expected. Once the test case iswritten, no human intervene is needed thus the test case doesall and indicate[12].Adequate testing of software trials prevent this tragediesto occur. Adequate testing however, can be difficult if thesoftware is extremely large and complex. This is because theamount of time and efforts required to execute a large set of test cases or regression test cases be significant [3]. Therefore,the more testing can be done with accuracy of test cases whichassist in corresponding rise in program transformation.Amongst different types of program transformation,behavior-preserving source-to-source transformations areknown as refactorings [2]. Refactoring is the process of changing a software system in such a way that it does not alterthe external behavior of the code yet improves its internalstructure [8].The refactoring concept was primarily assigned tosource code changes. The refactoring of test case may bringadditional benefits to software quality and productivity, vis-a-vis cheaper detection of design flaws and easy exploration of alternative design decisions. Consequently, The term coderefactoring and test case refactoring can be made distinct. Thus,one of the main reasons for wide acceptance of refactoring as adesign improvement technique and its subsequent adoption byAgile software methodologies, in particular eXtremeProgramming (XP) [1]. The XP encourages the developmentteams to skip comprehensive initial architecture or designstages, guiding them its implementation activities according touser requirements and thus promoting successive coderefactorings when inconsistencies are detected.II.
T
EST
-D
RIVEN
D
EVELOPMENT
Test Driven Development (TDD) is the core part of theAgile code development approach derived from eXtremeProgramming (XP) and the principles of the Agilemanifesto. It provides to guarantee testability to reach anextremely high test coverage, to enhance developer confidence,for highly cohesive and loosely coupled systems, to allowlarger teams of programmers to work on the same codebase, as the code can be checked more often. It alsoencourages the explicitness about the scope of implementation. Equally it helps separating the logical andphysical design, and thus to simplify the design, when only thecode needed.The TDD is not a testing technique, rather adevelopment and design technique in which tests are writtenprior to the production code. The tests are added its graduallyduring its implementation and when the test is passed, thecode is refactored accordingly to improve the efficacy of
(IJCSIS) International Journal of Computer Science and Information Security,Vol. 8, No. 8, November 201096http://sites.google.com/site/ijcsis/ISSN 1947-5500
,
internal structure of the code. The incremental cycle isrepeated until all functionality is implemented to final.The TDD cycle consists of six fundamental steps:1. Write a test for a piece of functionality,2. Run all tests to see the new test to fail,3. Write corresponding code that passes these tests,4. Run the test to see all pass,5. Refactor the code and6. Run all tests to see the refactoring did not change theexternal behavior.The first step involves simply writing a piece of code toensure the tests of desired functionality. The second is requiredto validate the correctness of test, i.e. the test must not pass atthis point, because the behavior under implementation must notexist as yet. Nonetheless, if the test passes over, means thetest is either not testing correct behavior or the TDD principleshave not been strictly followed. The third step is the writing of the code.
Figure - 1
However, it should be kept in mind to only write as littlecode as possible to enable to pass the test. Next, step is to seethat the change has not introduced any of the problemssomewhere else in the system. Once all these tests are passed,then the internal structure of the code should be improved byrefactoring. The afore mentioned cycle is presented in Fig 1.
III.
R
EFACTORING
The Program restructuring is a technique for rewritingsoftware may be useful either for legacy software as well as forthe production of new systems[ 6, 8,11]. If the internalstructure is changed, although the behavior (what the programis supposed to do) is maintained. Restructuring re-organizes thelogical structure of source code in order to improve specificattributes [8] or to make it less error-prone when future changesare introduced [11].Behavior preserving program changes are known asrefactorings which was introduced by Opdyke [10]. Yet it’sgaining importance by Fowler's work [5] and eXtremeProgramming (XP) [1], an Agile software development incontext of object-oriented development. In this context, arefactoring is usually composed of a set of small and atomicrefactorings, after which the largest source code is better thanthe original with respect to particular quality attributes, such asreadability and modularity.Thus, refactoring can be viewed as a technique for softwareevolution through-out software development and maintenance.Software evolution can be classified into the following types[7]:- Corrective evolution: correction of errors;- Adaptive evolution: modifications to accommodaterequirement changes;- Perfective evolution: modifications to enhance existingfeatures.Refactoring is mostly applied in perfective softwareevolution, though it also affects corrective and adaptiveevolution. First, well-organized and flexible software allowsone to quickly isolate and correct errors. Second, such softwareensures that new functionality can be easily added to addresschanging user requirements.A known issue about refactoring is automatization.Small steps of refactoring have usually been performedmanually, using primitive tools such as text editors with searchand replace functionality. This situation eventually leads tocorrupt the design of source code, mostly due to the fact thatmanual refactoring is tedious and prone to errors [2]. Althoughthe choice of which refactoring to apply is naturally made byhuman, automatic execution of refactorings might result in amajor improvement in productivity.In addition, concerning behavior preservation, TDDinformally guides refactoring assisted by unit tests, increasingthe correctness of a sequence of transformations. Furthermore,verification of object-oriented programs is highly nontrivial. Anumber of recent research initiatives have pointed outTestTestTest
Write a TestRun the TestModify CodeRun the TestRemoveBugRefactor
Run the Test
(IJCSIS) International Journal of Computer Science and Information Security,Vol. 8, No. 8, November 201097http://sites.google.com/site/ijcsis/ISSN 1947-5500
,
directions for formally justifying refactorings. In Opdyke'swork, preconditions for refactorings are analyzed [10], whereasRobert's work formalizes the effect of refactorings in terms of postconditions, in order to build efficient refactoring tools [2].In contrast, Mens [9] apply graph representation to aspects thatshould be preserved and graph rewriting rules as a formalspecification for refactorings.IV.
C
AUSES OF
R
EFACTORING
In computer programming, code smell is anysymptom in the source code of a program that possiblyindicates a problem at steep level.Often the deeper problem hinted by a code smell canbe uncovered when the code is subjected to a shortfeedback cycle where it is refactored in small, controlledsteps, and the resulting design is examined to assist theneeds of more refactoring. From the programer’s point of view, code smells are forecast to refactor, and whatspecific refactoring techniques are to be used. Thus, acode smell is a driver for refactoring. Code smell hint thatprovides can be improved in some where in your code.Determining a code smell is often a subjective judgment and will often vary by language, developer andits methodology. There are certain tools, such asCheckstyle, PMD and FindBugs for Java, to automaticallyevaluate for certain kinds of code smells.When to apply refactorings to the test code, is differentfrom refactoring production code and the test code has adistinct set of smells dealing with the test cases are organized,to study its implementation and interaction with each other.Moreover, improving test code involves a mixture of refactorings from specialized to test code improvements aswell as a set of additional refactorings involving themodification of test classes, ways of grouping test cases, andso on[5].
Refactoring (to Patterns)
• Simple Design -> Code Smell -> Refactor• Refactoring ( to Patterns) is the ability to transform a“Code Smell” into a positive design patternFollowing are the examples of some of the Bad CodeSmells that are encountered in case (unit/class) design• Duplicated Code• Methods too big• Nested “if” statements• Classes with too many instance variables• Classes with too much code• Strikingly similar subclasses• Too many private (or protected) methods• Similar looking code sections• Dependency cycles• Passing Nulls To Constructors• Classes with too little codeV.
T
EST
C
ASE
C
ODE
S
MELLS
This section gives an overview of bad code smells that arespecific for test code.
A.
Self Contained
When a test uses external resources, such as file containingtest data, the test is no longer self contained. Consequently,there is no enough information to understand the testfunctionality, to use it as test documentation.Moreover, external resources introduces hiddendependencies: if some force mutates such a resource, tests startfailing. Chances for this increase becomes more when moretests use the same resource. The use of external resources canbe thus eliminated using refactoring Intregral Resource.
B.
Resource Optimism
Test code that makes optimistic assumptions about theexistence (or absence) and state of external resources (such asparticular directories or database tables) can causenondeterministic behavior in test outcomes. The situationwhere tests run fine at one time and fail miserably at the othertime needs to be avoided. Resource Allocation refactoring usedto allocate and/or initialize all resources that are to be used.
C.
Resource Interface
Such wars arise when the tests execute you are the only onetesting which fails when more programmers run them. This ismost likely caused by Resource Interference: some tests in yoursuite allocate resources such as temporary files that are alsoused by others. Identified Uniquely is one of the test coderefactoring method used to overcome Resource Interference
.
D.
Setup Method
In the JUnit framework a programmer can write a setUpmethod that can be executed before each test method to create afixture for the tests to run. Things start to smell when the setUpfixture is too general and different tests only access part of thefixture. Such setUps are harder to read and understand.Moreover, they may make tests run more slowly (becausethey do unnecessary work). The danger of having tests that taketoo much time to complete is that testing starts interfering withthe rest of the programming process and programmerseventually may not run the tests at all.
E.
Splitting Method
When a test method checks methods of the object to betested, it is hard to read and understand, and therefore moredifficult to use as documentation. Moreover, it makes testsmore dependent on each other and harder to maintain. Thesolution is simple: separate the test code into test methods thattest only one method. Note that splitting into smaller methods
(IJCSIS) International Journal of Computer Science and Information Security,Vol. 8, No. 8, November 201098http://sites.google.com/site/ijcsis/ISSN 1947-5500
Search History:
Result 00 of 00
00 results for result for
p.
Improve the Test Case Design of Object Oriented Software by Refactoring
This Refactoring is the process of changing a software system aimed at organizing the design of source code, making the system easier to change and less error-prone, while preserving observable behavior. This concept has become popular…
(More)
548
Reads
1
Readcasts
0
Embed Views
More From This User
Notes
Load more
