Regression Aware Debugging for Mobile Applications Rohan Bavishi Awanish Pandey Subhajit Roy Department of Computer Science and Engineering, Indian Institute of Technology Kanpur, India. {rbavishi, awpandey, subhajit}@iitk.ac.in Abstract Regression-aware fault localization attempts to rank suspicious statements in a manner such that potential regression inducing suggestions are ranked low. The algorithm extracts the proof of correctness of all the correct executions in the form of Craig Interpolants over the successful execution traces. It, then, labels a program location suspicious if it can find a possible value for the assignment that can allow the hitherto failing execution to produce the expected output. However, any such value that does not satisfy the proof constraints of the passing tests are penalized in terms of their ranking. In this article, we sketch the regression-aware fault localization algorithm and motivate its potential application in debugging mobile applications. Categories and Subject Descriptors D.2.5 [Software Engi- neering]: Testing and Debugging; F.3.1 [Logics and Mean- ings of Programs]: Specifying and Verifying and Reasoning about Programs Keywords Debugging, fault localization 1. Introduction This is an era of smart devices—from smart-watches to cell- phones and tablets, mobile applications have become an integral part of our lives. The amount of software developed in this domain necessitates support for effective testing and debugging. One potent debugging technique is fault localization: given a failing test, a fault localization algorithm suggests potential program statements that can be ”repaired” to cor- rect the failing execution; we refer to such statements as suspicious statements. However, many such suggestion may induce regression—though there exist possible alterations to these statements that can ”repair” the failing execution, but any such modification could lead to the failure of a hitherto passing test-case. Regression-aware fault localization [1] at- tempts to rank the suspicious statements such that potential regression inducing suggestions are ranked low. We illustrate our algorithm using the code snippet shown in Figure 1. The program is an abstraction of a graphi- cal user-interface (GUI) based event-driven program de- scribed in a C-like language. The program encodes the essence of a sprite-based game: the handle user input() method detects the keypress events and moves the player’s sprite by translating its bounding box. Every time the player moves, the handler also detects if it collides with the sta- tionary objects around it (for simplicity, we show only a single object) using the detect collision() routine; the boolean variable collision detected trips to true any time a collision happens. The main() procedure installs the key- press event handler using Handle User Input() such that the handle user input() routine is invoked at every key- press. The Check Desired Collision State() routine pro- vides the correctness specification by asserting if the state of the collision detected variable is indeed correct. The tests for such a routine would include a sequence of keypress events and the expected outcome is the state of the collision detected flag. Such tests can be produced by hu- man testers or automatically generated from tools like the UI/Application Exerciser Monkey[3]. Table 1 shows a set of tests (column 2), their expected outcome (column 3 labelled ‘Collision Occurs’), the actual outcome from the program captured as the state of the variable collision detected (column 4 labelled ‘Collision Detected’) and the test out- come (column 5) for the given program. The program listed in Figure 1 is faulty and the bug lies in lines 21 and 22: it fails when the player’s bounding box exactly overlaps with that of the object (the bounding boxes of the player and the object have the same dimensions). The correct expression is provided as a comment on line 19. This is precisely the reason why the fifth test fails: the player moves right once, moves up twice, and then moves right again; this aligns the player exactly with the object, but the collision is still not detected (due to the bug described above). In the four passing tests, the player is either moving away from the object or its bounding box intersects partially with that of the object.