Erlang Code Evolution Control

Silva

Tamarit

2019

Scientific Programming

Self Cite

Program slicing is a technique to extract the part of a program (the slice) that influences or is influenced by a set of variables at a given point (the slicing criterion). Computing minimal slices is undecidable in the general case, and obtaining the minimal slice of a given program is normally computationally prohibitive even for very small programs. Therefore, no matter what program slicer we use, in general, we cannot be sure that our slices are minimal. This is probably the fundamental reason why no benchmark collection of minimal program slices exists. In this work, we present a method to automatically produce quasi-minimal slices. Using our method, we have produced a suite of quasi-minimal slices for Erlang that we have later manually proved they are minimal. We explain the process of constructing the suite, the methodology and tools that were used, and the results obtained. The suite comes with a collection of Erlang benchmarks together with different slicing criteria and the associated minimal slices.

Section: Implementation Of the Methods For Erlangmentioning

confidence: 99%

“…However, in our case, these inputs must be complemented with very speci c outputs to form the test cases: the sequences of values the slicing criterion is evaluated to. In our case, this is done by a tool called SecEr [25] (which implements function seq in Algorithm 1). Given a…”

Section: Test-case Validationmentioning

confidence: 99%

Automatic Testing of Program Slicers

Silva

Tamarit

2019

Scientific Programming

Self Cite

“…For instance, Travis CI can be easily integrated in a GitHub repository so that each time a pull request is performed, the test suite is launched. Point of interest (POI) testing [9,11,12] (briefly described in section 2) is an alternative and complementary approach that creates an automatic test suite to do regression testing: (i) An alternative approach because it can work as a standalone way without the need of using other techniques. Therefore, POI testing can check the evolution of the code even if no test suite has been defined.…”

Section: Introductionmentioning

confidence: 99%

Enhancing POI Testing Through the Use of Additional Information

Functional and Constraint Logic Programming

Tamarit

2019

Self Cite

Recently, a new approach to perform regression testing has been defined: the point of interest (POI) testing. A POI, in this context, is any expression of a program. The approach receives as input a set of relations between POIs from a version of a program and POIs from another version, and also a sequence of input functions, i.e. test cases. Then, a program instrumentation, an input test case generation and different comparison functions are used to obtain the final report which indicates whether the alternative version of the program behaves as expected, e.g. it produces the same values or it uses less CPU/memory. In this paper, we explain how we can improve the POI testing approach through the use of common stack traces and a more sophisticated tracing for calls. These enhancements of the approach allow users to identify errors earlier and easier. Additionally, they enable new comparison modes and new categories of reported unexpected behaviours.2 Steps (ii) and (iii) could also be executed in parallel. Here, for the sake of simplicity, we only consider the sequential execution of these steps.

“…SecEr reports that no discrepancies exist $ ./secer -f string0.erl -li 2 -var Res -oc 1 -f string1.erl -li 2 -var Res -oc 1 -funs [main/2] -to 15Function: tokens/2 ----------------------------Generated test cases: 7044Both versions of the program generate identical traces for the defined points of interest----------------------------Listing 1.9. SecEr reports discrepancies after modifying optimized string.erlFunction: tokens/2 ----------------------------Generatedtest cases: 6576 Mismatching test cases: 5040 (76.64%) POIs comparison: + {{'string0.erl',2,{var,'Res'},1}, {'string1.erl',2,{var,'Res'},1}} Unexpected trace value => 5040 Errors Example call: tokens([12,4,5],[2,3,2,5,0,1]) ------Detected Error ------Call: tokens([12,4,5],[2,3,2,5,0,1]) Error Type: Unexpected trace value POI: ({'string0.erl',2,{var,'Res'},1}) trace:[[[12,4]]] POI: ({'string1.erl',2,{var,'Res'},1}) trace:[[4,[12,4]]] ---------------------…”

mentioning

confidence: 99%

“…(2,6) ------Detected Error ------Call: main(2,6) Error Type: Unexpected trace value POI: ({'happy0.erl',9,{var,'Happy'},1}) trace: [false,false,false,false,false,true,false,false,true,false,false,true,false,false,false,false, false,true,false,false,false,true,false,false,false,false,true] POI: ({'happy1.erl',17,{var,'Happy'},1}) trace: [false,false,false,false,false,false,false,false,true,false,false,true,false,false,false,false, false,true,false,false,false,true,false,false,false,false,true,false,false,true]…”

unclassified

Erlang Code Evolution Control

Insa

Logic-Based Program Synthesis and Transformation

Silva

et al. 2018

Self Cite

The main goal of this work is to show how SecEr can be used in different scenarios. Concretely, we demonstrate how a user can run SecEr to obtain reports about the behaviour preservation between versions as well as how a user can use SecEr to find the source of a discrepancy. The use cases presented are three: two completely different versions of the same program, an improvement in the performance of a function and a program where an error has been introduced. A complete description of the technique and the tool is available at [1] and [2]. Use case 1: Happy numbersIn order to show the potential of the tool, we provide an example to compare two versions of an Erlang program that computes happy numbers. Concretely, these two versions are based on completely different algorithms. Therefore, this use case shows that SecEr is able to deal with such scenarios where the correspondence between versions is not direct. Both of them are taken from the Rosetta Code repository: 1 http://rosettacode.org/wiki/Happy _ numbers#Erlang.