Property generation/verification and empirical studies

Abstract

This issue contains four papers. The first and third papers focus on property generation and property verification, respectively, while the second and fourth papers focus on empirical studies of a fault prediction algorithm and test flakiness, respectively. The first paper, “Documentation-based functional constraint generation for library methods,” by Renhe Jiang, Zhengzhao Chen, Yu Pei, Minxue Pan, Tian Zhang, and Xuandong Li, proposes DOC2SMT, an approach that generates functional constraints for library methods based on their documentations. DOC2SMT first translates a method’s documentation into candidate constraint clauses, which are then filtered based on static and dynamic validations. The experimental results show the effectiveness and efficiency of DOC2SMT and also show the benefits of the generated constraints for symbolic-execution-based test generation (recommended by Peter Müller). The second paper, “An empirical study of Linespots: A novel past-fault algorithm,” by Maximilian Scholz and Richard Torkar, proposes a new fault prediction algorithm called Linespots. The authors focus on fault prediction based on past faults and refine a previous algorithm (Bugspots). Interestingly, they used a different granularity: line as opposed to file, and this necessitated the development of a benchmark set of experimental subjects. In experiments, Linespots was found to outperform Bugspots (recommended by Xiaoyin Wang). The third paper, “Integrating pattern matching and abstract interpretation for verifying cautions of microcontrollers,” by Thuy Nguyen, Takashi Tomita, Junpei Endo, and Toshiaki Aoki, proposes a semi-automatic approach for verifying cautions, which are hardware-dependent properties described in microcontrollers hardware manuals. For this approach, the authors integrate pattern matching and abstract interpretation, two static program analysis techniques. The experimental results show the feasibility and applicability of the approach (recommended by Marcio Delamaro). The fourth paper, “Empirical analysis of practitioners’ perceptions of test flakiness factors,” by Azeem Ahmad, Ola Leifler, and Kristian Sandahl, concerns flaky tests. A flaky test is one where different executions with the same test can lead to different outcomes/verdicts. The authors explore developer perception regarding factors that affect flakiness, concentrating on developers of closed-source software. They also examine two test suites and identify the test smells that lead to flakiness (recommended by Mike Papadakis).