but possibly incorrect patches by, for
example, favoring smaller patches or
favoring patches “similar” to human
patches. Nevertheless, the developer
still needs to explore the remaining
large set of patch suggestions.
Explaining repairs. A strongly related problem is to explain repair suggestions. One idea worth pursuing
is to compute and present the correlation of patches based on program
dependencies and other semantic
features, which allow the developer
to loosely group together plausible
patches. Explaining repairs is needed
particularly in its application to programming education. 40 Instead of
merely fixing a students’ incorrect
program to the model correct program, it is useful for the repair tool to
generate hints of what is missing in
the students’ repair. Such hints may
take the form of logical formulae capturing the effect of repairs, which are
gleaned from constraint-based repair
tools; these hints may be presented in
natural language, instead of logic, for
easy comprehension by the learners.
Conclusion
Automated program repair remains an
enticing yet achievable possibility that
can improve program quality while improving programmers’ development
experience.
Technically speaking, automated
repair involves challenges in defining,
navigating, and prioritizing the space
of patches. The field benefits from past
lessons learned in search space definition and navigation in software testing,
as embodied by the vast literature in
test selection and prioritization. The
GenProg tool37 is just one example of
how genetic search, which has been
useful for testing, can be potentially
adapted for repair. At the same time,
automated repair comes with new challenges because it may generate patches
that overfit the given tests. This is a
manifestation of tests being incomplete correctness specifications. Thus,
there is a need for inferring specifications to guide repair, possibly by program analysis. The Semfix and Angelix tools16, 18 are a few examples of how
the repair problem can be envisioned
as one of inferring a repair constraint,
and they have shown the scalability of
such constraint-based techniques.
programs as well as large search spaces
(complex changes).
Development process. The final
challenge is about integrating repair
tools into the development process.
Integration with bug detection. Bug
detection is the natural step preceding
program repair. It is possible to fuse
debugging and repair into one step, by
viewing repair as the minimal change,
which makes the program pass the
given tests. We envision future work
integrating repair with bug detection
techniques, such as static analysis
tools. Doing so may enable repair techniques to obtain additional information about possible repairs from static
analyses, in addition to the test cases
used nowadays. As a first step in this
direction, a static analysis infrastructure used at Google suggests fixes for
a subset of its warnings. 23 A promising
future direction here could be to extend static analysis tools for generating dynamic witnesses or scenarios of
undesirable behavior.
IDE integration. Most of today’s
repair tools are research prototypes.
Bringing these tools to the fingertips
of developers in a user-friendly fashion
will require efforts toward integrating
repair into integrated development
environments (IDEs). For example, an
IDE-integrated repair tool could respond to either failed unit or system
tests or developer prompting. To the
best of our knowledge, this application has not yet been widely explored.
Suitably interactive response times are
a precondition for such an approach.
This research direction will benefit
from interaction with experts in developer tooling and human-computer interaction, to ensure tools are designed
and evaluated effectively.
Interactivity. As program repair
gets integrated into development environments, interacting with the developer during repair is important.
While the focus in the past decade has
been on fully automated repair, putting the developer back into the loop
is necessary, in particular, due to the
weak specifications (test suites) often
used to guide program repair. User
interactivity may be needed to yield
expected outputs of additional test
inputs that are generated to strengthen the test-suite driving repair. 27 It is
of course possible to filter plausible
Automated
program repair
remains an enticing
yet achievable
possibility that
can improve
program quality
while improving
programmers’
development
experience.