Test Generation Clause Samples

Test Generation. We extended a popular random test generator, Randoop [▇▇▇▇▇▇▇ and ▇▇▇▇▇ 2007], to collect only relevant tests. Note that whether a test is relevant is decided at runtime while Randoop is generating tests. In our initial experiment, it took too long (almost five minutes in some instances) for Randoop to start generating relevant tests. We made a couple of simple changes to Randoop to alleviate the problem. First, our test generator selects the seed method with a 50% chance from specified target methods, unlike the original Randoop that selects the seed method from all legal methods that are in the scope of the tool. As target methods, we used either: (i) the target method m of a change contract if m is public or (ii) public callers of m if m is not public. Such target method specification can be automated with the help of static analysis. The reason for assigning a 50% chance to the target methods (as opposed to assigning 100% chance) is that, otherwise, Randoop does not consider other method calls that may be necessary for constituting a relevant test. The second change we made to Randoop is to address the following problem we found in our initial experiments. It took particularly long for Randoop to generate relevant tests in a case where the update condition of a change contract is satisfied only if void- type methods are called to change the program state properly before the target method is called. For example, if a target method is m2(int i), then the unmodified Randoop opts for generating a sequence that ends with “m2(var2);” preceded by a sequence of statements that ends with a statement to assign a value to variable var2, such as “var2=m1(var1);”. This statement is again preceded by another statement to assign a value to var1. Such a style of ▇▇▇▇▇▇▇’s sequence generation tends to exclude void-type method calls in the middle of a sequence. To address the previous issue, we intersperse a statement sequence with random void-type method calls. We also transform statements like “var1.m1(); var2.m2();” into “var2.m1(); var2.m2();” to merge the receivers. We let such a transformation take place with an 80% chance in our experiments. Note that generally there is no guarantee that executing a relevant test in the updated system will execute the target method with isomorphic input because only the previous version was considered when constructing relevant tests. Obviously, by considering the updated system as well, this problem can be avoided in exchange fo...