Dead eld is one of the most common test smells found in the test code which is responsible for degrading performance and creating misapprehension about the code. The reason of its occurrences is that in most of the cases, developers initialize setup elds without considering the usage of those elds in the test methods. In this paper, an automatic dead eld identi cation technique is proposed where the test code is statically searched for identifying the usage of all the setup elds. It does so by guring out all the setup elds which are initialized in the setup method or its invoked methods. After that, it detects such elds which are used by at least one test method directly or indirectly. In addition, eld dependency is resolved to nd all the elds on which used setup elds depend. At last, all the unused setup elds are gathered and considered as dead elds. To evaluate the technique, it was implemented in the form of a tool and two open source projects were run on it. It has been seen that it identi es all the dead elds in those projects correctly and performs better than existing dead eld detection techniques.
Dead elds are the initialized elds in the setup method of a test class that are never used by any test method. However, manually scrutinizing test code to nd dead elds slows down the production of software, and may induce bugs while applying refactoring methods to stump out this smell. On the other hand, when test code fails to convey its intent is considered to have the test smells which have no impact on the behavior of the test code but causes the attrition of the test code quality. Dead eld is one of those which degrades the performance of the test code as well as maintainability by unnecessarily using computational resources and creating misunderstanding among the developers. So, dead elds should be identi ed and removed from the test code to maintain the quality. Dead elds can be identi ed by analyzing the test xtures and test methods in the test code. However, the major challenges are to nd all setup elds in the test xtures, resolve eld dependency among those and gure out the usage of those elds in test methods automatically.
Generally, a test xture de nes the con guration of the system under test including setup methods. Those setup methods are invoked before execution of any test case to ensure that all the setup elds are initialized properly for running the test cases. On the other hand, after preparing the system for testing, test methods use their required setup elds directly or indirectly through invoking other method(s). To identify dead elds, unused setup elds are required to be detected for which all the setup elds and their usage in the test methods are needed to be analyzed. However, in order to identify setup elds, all the setup methods in the test xture are required to be analyzed. In addition, to nd the usage of the setup elds, dependency relationship among the setup elds and those elds' usage in test methods need to be resolved.
Martin Fowler coined code smell [
In this research, a technique named Dead Field Identi er (DFI) is proposed to identify dead elds automatically by analyzing usage of setup elds and eld dependency in test methods. Initially, all the elds in the test code are searched and gathered from test code. As header elds2 are also considered as setup elds, so all the header elds are gured out from the identi ed elds by parsing the code. Later, setup method and all other methods invoked directly or indirectly by it are identi ed. The body of those methods are extracted to nd all the setup elds in the code. To nd usage of those elds, all the test methods and other methods invoked by those are obtained and elds which are used in those methods are detected. Usually, it is found in the code that a setup eld which is used in at least one test method may depend on one or more other setup elds which are never used by any test method. So, those elds are identi ed through analyzing eld dependency among the setup elds and considered as used setup elds. At the end, all unused elds are separated from the setup eld list and those are marked as dead elds. 1 http://www.swerl.tudelft.nl/twiki/pub/MichaelaGreiler/TestHound/TestHound 2 Header elds are those elds which are initialized in the class header
In order to assess the technique, a tool is implemented based on it. The
proposed technique requires test code related information like elds in the test class,
method signature, method body etc. For this reason, test code is converted into
compiler centric Abstract Syntax Tree (AST) by the tool where AST is a
semistructured form of the code [
The rest of the paper is organized as follows. Section 2 describes related works in detecting dead elds. The proposed technique is discussed in Section 3. Section 4 presents implementation and result analysis of the proposed technique. Conclusion is drawn in Section 5. 2
The presence of dead eld in the test code indicates incomplete or deprecated software development activities. This smell is a recent contribution in the literature. Several researches have been carried out so far for analyzing the impact of test smells in the test code. Besides, researchers proposed di erent techniques to identify and remove those smells from the code. These are outlined as follows.
van Deursen et al. rst described the concept of test smells [
A metrics-based approach was proposed by Bart van Rompaey et al. [
method of a test case, and number of production type used in the test code. They also de ned xture size as number of xture elements and production type in the xture. For eager test identi cation, they used production type method invocation as metric which is the number of invocations to the methods in the production code from a test command. Their result was compared against manual inspection. The technique worked well in identifying test xture and eager test smell. However, the metrics that were used to identify those smells are not adequate enough to detect dead eld in the test code as its characteristics are di erent.
In order to understand the distribution of unit test smells and the impact
of those smells on software maintenance, Gabriele Bavota et al. conducted an
empirical analysis regarding this [
Stefan Reichhart et al. developed a tool named TestLint for assessing the
quality of test code [
Manuel Breugelmans and Bart van Rompaey presented a tool called TestQ
for exploring structural and maintenance characteristics of unit test suites [
A static analysis technique to identify test xture related smells in the test
code was presented by Michaela Greiler et al. [
Although dead eld is a recently introduced test smell in the literature, some signi cant works have been performed in identi cation of test smells so far. Researchers explained the impact of test smells in test code maintenance and proposed di erent techniques to detect test smells like metrics based approach, rule based assessment, test xture analysis and so on. Some of those could identify dead elds in the test code but the outcome is not accurate enough. Sometimes it is seen that those techniques provides false positive result which ultimately induces serious impact while managing the code. For that reason, test code is needed to be inspected manually for making sure the correctness of the result in dead eld detection. So, automatically identifying dead elds in the code properly is still an open problem in the literature. 3
The intent of this research is to develop a technique named Dead Field Identi er (DFI) to identify dead elds in the test code for making the code more maintainable and comprehensible by removing those elds. For the identi cation, rstly, it is required to identify all the invoked methods for any method in the test code. In addition, all the setup elds are required to be obtained and usage of those elds are needed to be identi ed in the code which assist to detect dead elds. So the technique for the identi cation comprises several steps like invoked method identi cation, setup eld detection, nding usage of setup elds and dead eld identi cation which are described in the following subsections.
Require: A method (M ) for which all the methods invoked directly or indirectly by it will be identi ed and an empty list L to store invoked methods 1: procedure GetAllInvokedMethod(M ) 2: if M 2= L then 3: add M into L 4: end if 5: initialize an empty list N to store methods invoked by M 6: get all methods invoked by M through parsing its body 7: store those methods into the list N 8: for each m 2 N do 9: A GetAllInvokedMethod(m) 10: Insert all items in A into L 11: end for 12: return L 13: end procedure
Invoked Method Identi cation In order to identify invoked method(s) in the test code Algorithm 1 is developed. Usually, the rst step to identify dead elds in the test code is to identify all the methods invoked directly or indirectly by any method in the code. This is required because elds in the test class may be initialized by any method invoked directly or indirectly by the setup methods. Even setup eld(s) may not be used directly by a test method but may be used by other methods which are invoked by the test method directly or indirectly.
In Algorithm 1, the procedure GetAllInvokedM ethod takes a method as input and returns a list of all methods invoked directly or indirectly by the method. For this, rst of all, a list is initialized to store all invoked methods and the body of the inputted method is parsed to identify all the methods invoked by it which are inserted into another list (Algorithm 1 Line 5-7). A loop is used to identify all the invoked methods for each method in the list by recursively calling GetAllInvokedM ethod. For each iteration, the corresponding method is also added into the list which is responsible for containing all invoked methods (Algorithm 1 Line 8-11). 3.2
Finding Setup Fields Setup elds in the test code are those which are initialized in the implicit setup procedures or the class header. All the setup elds in the test code are required to be identi ed because such setup elds are considered as dead elds which have never been used by any test method in the test code.
Algorithm 2 describes a procedure GetAllSetU pF ields which works on given test code and provides a list of all setup elds in the code. Initially two lists are initialized - one is to store all setup elds and another is to store all the elds by parsing the test code (Algorithm 2 Line 2-3). In the loop, all the header elds are identi ed from the list of elds and those are added to the setup eld list as header eld is also considered as setup eld (Algorithm 2 Line 4-8). After that, from rest of the elds those which are initialized in the implicit setup are added to the list of setup elds (Algorithm 2 Line 9-22). 3.3
Finding Usage of Setup Fields After identifying all setup elds following the previous step, the usage of all these elds are required to be found in the test code. This will help to detect which setup elds are never been used by any test method in the test code.
In Algorithm 3, all the test methods and all the setup elds in the test code are identi ed and stored in two di erent lists respectively (Algorithm 3 Line 3-5). For each identi ed test method, the procedure GetAllInvokedM ethod is called to obtain all the methods invoked directly and indirectly by the method (Algorithm 3 Line 6-8). After that, the body of each invoked method and the test method are checked to identify which setup elds are used in the body and such elds are added to the used setup eld list (Algorithm 3 Line 9-16). At last, the
Require: Test code T for identifying all setup elds in T 1: procedure GetAllSetUpFields(T ) 2: initialize an empty list S to store setup elds 3: identify all the elds in T using parser and store those elds in the list F 4: for each f 2 F do 5: if f is header eld then 6: Add f to S 7: end if 8: end for 9: nd setup method M by parsing T 10: create an empty list I to store method 11: I GetAllInvokedMethod(M ) 12: add M to I 13: for each m 2 I do 14: for each f 2 F do 15: if f 2 S then 16: continue 17: end if 18: if f is initialized in m then 19: add f to S 20: end if 21: end for 22: end for 23: return S 24: end procedure
Require: Test code T for nding usage of setup elds in the test code 1: procedure GetAllUsedSetUpField(T ) 2: initialize an empty list U to store all used setup elds in T 3: initialize an empty list M to store all test methods in T 4: identify all test methods by parsing T and add those into M 5: S GetAllSetUpFields(T ) 6: for each m 2 M do 7: L GetAllInvokedMethod(m) 8: add m to L 9: for each i 2 L do 10: Get the body of the method (i) and save it in b 11: for each f 2 S do 12: if f is used in b and f 2= U then 13: add f to U 14: end if 15: end for 16: end for 17: end for 18: return U 19: end procedure
Require: Test code T to identify dead elds in the code 1: procedure GetAllDeadField(T ) 2: S GetAllSetUpFields(T ) 3: U GetAllUsedSetUpField(T ) 4: F S U 5: initialize a list D to store dead elds 6: for each f 2 F do 7: f lag f alse 8: for each i 2 U do 9: if i depends on f for initialization in the implicit setup then 10: f lag true 11: end if 12: end for 13: if f lag = f alse then 14: add f to D 15: end if 16: end for 17: return D 18: end procedure list of all used setup elds are returned by the procedure GetAllU sedSetU pF ield (Algorithm 3 Line 18). 3.4
Dead Fields Detection Subsection 3.3 provides all the setup elds that are used by at least one test method directly or indirectly. However, such setup elds can be found in the test code, which are not being used by any test method, but some used setup elds may depend on those elds for initialization. So, those elds are not considered as dead elds. For nding all those elds, incorporating those with the list of elds obtained using subsection 3.3 and nally providing a list of all identi ed dead elds in the test code, Algorithm 4 is used for implementation.
To detect dead elds, all the setup elds and used setup elds are gathered (Algorithm 4 Line 2-3). A list is used to store all the setup elds which are not used by any test method (Algorithm 4 Line 4). The nested loops identify which setup elds of the list are never used for the initialization of any used setup eld (Algorithm 4 Line 6-16). All those unused elds are considered as dead elds which are returned by the procedure GetAllDeadF ield as a list (Algorithm 4 Line 17).
Complexity Analysis The overall complexities of GetAllInvokedM ethod, GetAllSetU pF ields, GetAllU sedSetU pF ield, and GetAllDeadF ield are O(p), O(pq), O(prs), and O(pq + prs + mn) respectively. Here, p, q, r, s, m and n are number of invoked methods, number of elds, number of test methods, number of setup elds, number of unused setup elds, and number of used setup elds correspondingly.
In order to evaluate DFI, a tool is implemented based on it. TestHound [
Environmental Setup This subsection outlines the software tools required for the experimental analysis. For this analysis, DFI is developed using Java programming language. Although the tool works to identify dead elds in the test code written using Java, the approach proposed here is platform independent and only the facts extraction aspect is language speci c. So, the technique can easily be implemented in any programming language. Some other tools are also used in the experiment and those are addressed as follows.
{ Eclipse Juno5: Java IDE for the development of DFI { Byte parser6: Java byte code parser which has been developed to parse java byte code and construct AST { Maven7: Apache build manager for building the java projects used as the dataset in the experiment
For the analysis, two open source projects have been used which are depicted in Table 1. One of those is EquationSolverTest which is developed to solve equation having di erent expressions. It is an open source project and it has 800 lines of code as well as 4 test classes. Another is eGit which is also an open source Eclipse integrated version control system. It consists of 130K lines of code and 87 test classes. Both are available in the GitHub. As we have said above, two di erent sized projects are used for the experiment to observe the behavior of the proposed technique. One of those is eGit which is
large in size, and another is EquationSolverTest which is comparatively small. The results obtained using those projects are explained as follows.
Result Analysis for EquationSolverTest: For comparative analysis, initially the project EquationSolverTest is run by TestHound and DFI. In addition, manual inspection is also performed on the code. Table 2 summarizes the result produced by the tools and manual inspection. In the table, it is seen that there are four test classes. Comparative analysis for those classes are described below.
For the test class SimulateEquationTest, TestHound can not identify any setup eld whereas DFI detects 5 setup elds as well as 4 dead elds from those. The outcome of DFI is equal to the result of manual inspection. The reason is that TestHound can not identify those setup elds which are initialized in the methods invoked by setup method, but DFI considers all those methods and checks the initialization of setup elds.
In the test class ExpressionFormatterTest, there are 4 setup elds where one is header eld and others are initialized through indirect method invocation by the setup method. TestHound detects no usage of the header eld and thus, considers it as dead eld, but others are ignored because of the same reason as stated earlier. However, DFI identi es all those and recognizes as dead elds.
Both tools identify two dead elds correctly for the test class ExpressionSimulationResultTest. However, TestHound identi es 2 setup elds out of 7 because those two are header elds and rest 5 are initialized in the setup method which are not considered in it. On the other hand, DFI checks the setup method as well as header eld, that is why it detects all setup elds.
There is a single header eld in test class OperationTest and this eld is used in all 4 test cases. As both tools can detect header elds and usage of setup elds in test cases so those tools provide the same result for the test class.
Result Analysis for eGit: DFI is also run on a module of eGit named
org.eclipse.egit.core.test. There are 13 test classes and 46 test methods in total.
The result provided by the tool for the project is shown in Table 3. According
to the table, DFI identi es 78 setup elds and 6 dead elds. To ensure the
correctness of the result, manual inspection is performed and the same outcome is
produced. During manual inspection, it is found that test classes which extend
the same super class contain dead elds. This is because setup elds are
initialized in the super class but never been used by any test method in the subclasses.
However, DFI rst identi es all the elds of a test class. Later, all the inherited
elds are accumulated with those if the class extends another class. After that,
it identi es setup elds among those by analyzing all methods' body invoked by
the setup method and detects dead elds by nding usage of those elds in test
methods. For this reason, DFI's result is the same to the manual inspection's
outcome. However, 3% of the elds in this project could not be identi ed as eld
usage by TestHound [
DFI and TestHound, both can identify dead elds in the test code. However, TestHound can not detect dead elds correctly due to not handling some cases properly like setup elds initialization in a method invoked by setup method, eld dependency among setup elds, and usage of setup elds by test methods indirectly. On the other hand, DFI can appropriately deal with those and as a result it detects dead elds correctly in the test code. 5
The presence of dead elds in the test code reduces the manageability and comprehensibility of the code. To detect those elds in the code, an automatic identi cation technique is introduced. A tool is also implemented based on the technique which identi es dead elds in the test code.
The technique rst identi es all the elds in the test code through static code search. Setup elds are identi ed from those by analyzing the initialization of those elds in the setup method and its invoked method. At last, usage of those elds in test methods and dependency relationship among those elds are resolved to gure out dead elds in the code.
For the experimental analysis of the approach, two open source projects were run on it. The result of DFI was compared to another tool named TestHound. The experimental result shows that DFI identi es all the dead elds in those projects correctly and performs better than TestHound. In future, more open source projects and industrial projects will used to evaluate the technique. Acknowledgment This work is supported by the University Grants Commission, Bangladesh under the Dhaka University Teachers Research Grant NoRegi/Admn-3/2016/46897. The authors would like to thank Sheikh Muhammad Sarwar for his contribution in the revision phase of the paper.