![](bg2.png)
We’re going to discuss the problems of creating
unit tests to achieve high test coverage in the next
section and briefly describe the white–box testing
method. Our motivation and the reasons we have de-
cided to use Pex and create our extension is explained
in section 4. Our proposed solution is described in
next section 5. And section 6 concludes the results of
our work and describes our future work.
2 IN PURSUIT OF HIGH TEST
COVERAGE
Code that is unit tested since the very beginning is not
error–free, but the number of errors is reduced. Unit
tests are in most cases created by the developers at the
moment of writing the code or in worse case much
later. They are familiar with their code and know the
details of it and know how to write the tests quickly.
The pitfall is that they can introduce a false positive
error. The test does fail to indicate a problem or fail-
ure but it does not verify the correctness of the appli-
cation code. They might have not fully understood the
requirements or the test was created to test their own
incorrect code and system specifications and require-
ments were ignored. They have created a non–failing
test that verifies incorrect behaviour.
Code coverage is a metric used to describe the de-
gree to which the source code of a program is tested
by a test suite. The higher the number, the better.
But it is quite difficult to create unit tests manually
with very high test coverage. The most difficult is
testing the code paths that result in an exception be-
ing explicitly thrown — when constraint is broken
or a contract validation fails. Tester must set up the
test environment properly and infer the set of input
variables values that when passed to the method will
throw an exception. That means he has to have access
to the source code and be familiar with it. Significant
amount of time can be spent on analysing the code
and writing the test case than actual testing.
These corner cases can be tested using white–box
testing tool. We have decided to use a white–box test-
ing tool in our proposed system as it gives a better
insight into the internal structure of the tested code
and it can infer the minimal sets of significant input
parameter values.
2.1 Insight Into the Code
White–box tool test internal structures of an applica-
tion, in contrast to black–box testing when only the
public interfaces of the application are tested. The in-
ternals of an application can be analysed statically or
dynamically. Both having its advantages and disad-
vantages but supplementing each other. Static anal-
ysis analyses the code at a higher level than dynamic
analysis and can detect issues that are correct from the
viewpoint of dynamic analysis(Karpov, 2011).
White–box test case generators produce represen-
tative set of tests that can cover most of the applica-
tion code. Test case generator with insight into the
code minimizes the number of generated test cases to
achieve high test coverage.
JWalk(Simons, 2007) is white–box testing tool
targeting Java platform. It supports lazy systematic
unit testing. The tool infers dynamically the evolv-
ing specification of an application on the fly by dy-
namic analysis and uses the class state exploration and
then it tests the code systematically and exhaustively
to bounded depths.
Pex(Tillmann and de Halleux, 2008) generates
inputs for parametrized unit tests by analysing the
branch conditions in the .NET platform program. Test
inputs are chosen based on whether they can trigger
new branching behaviours of the program. The anal-
ysis using a dynamic symbol execution (DSE) (Cadar
and Sen, 2013) is an incremental process. It refines
a predicate along the execution path over the formal
test input parameters over the set of behaviours ob-
served previously. Variants of the previous inputs
are inferred by a constraint solver Z3 (de Moura and
Bjørner, 2008) in order to steer future program execu-
tions along alternative program path.
White–box testing tools help the developers to
create unit tests to test the code on low level. How-
ever it is important for the application to be tested
on higher levels — to meet the specification require-
ments, passing user acceptance testing, etc.
3 RELATED WORK
The solution proposed in (Alkhalaf et al., 2012) uses
minimum and maximum input validation policies to
validate user input. These policies are defined as reg-
ular expressions the input value must match. The
JavaScript validation must be defined beforehand and
the extraction is done in runtime, the extracted data
is then analysed using string analysis. In (server side,
2012) the authors are parsing the HTML code of the
page to locate the form and the input elements. For
every element a metadata is created and stored.
As observed in (Jamrozik et al., 2013), Pex does
not produce tests sensitive enough to make a good
regression test suite, sometimes the end users expect
different value or more values fitting given the condi-
tion or program path. A new tool extending Pex was
ICSOFT-EA2014-9thInternationalConferenceonSoftwareEngineeringandApplications
316