Obsolete and redundant tests increase regression testing costs. Therefore, developers should remove them from test suites; however, identifying these tests is non-trivial. Automated techniques for identifying obsolete and redundant tests could help developers reduce regression testing costs. Nonetheless, we have limited empirical evidence of how and why developers delete tests. Therefore, in this work, we first create DelTest, a dataset of 24,431 manually confirmed deleted tests, by analyzing 449,592 commits from seven open-source Java projects. We then perform an empirical study on DelTest to understand test deletion. Our findings show that test deletion frequency and the number of deleted tests vary significantly across projects, suggesting that test deletion is more likely driven by project-specific needs than the broader development cycle. Developers delete only one or two tests in most commits, suggesting test deletion is mostly small and incremental. In DelTest, 83.2% of tests are deleted along with the corresponding test classes, while $16.8 \%$ are deleted individually. We find that $91.4 \%$ of deleted tests in six projects are obsolete tests (i.e., production code is deleted), $7 \%$ are redundant tests (i.e., passing tests), and $1.6 \%$ are failing tests. The deletion of $20 \%$ of redundant tests reduces code coverage or mutation scores. We also evaluate test suite reduction (TSR) approaches on DelTEST and find that a TSR approach identifies up to 54% of the redundant tests. Our findings can help improve automated techniques for identifying obsolete and redundant tests.

Developers heavily rely on Application Programming Interfaces (APIs) from libraries to build their projects. However, libraries might become obsolete, or new libraries with better APIs might become available. In such cases, developers replace the used libraries with alternative libraries, a process known as library migration. Since manually migrating between libraries is tedious and error prone, there has been a lot of effort towards automated library migration. However, most of the current research on automated library migration focuses on Java libraries, and even more so on version migrations of the same library. Despite the increasing popularity of Python, limited research has investigated migration between Python libraries. To provide the necessary data for advancing the development of Python library migration tools, this paper contributes PyMigBench, a benchmark of real Python library migrations.PyMigBench contains 59 analogous library pairs and 75 real migrations with migration-related code changes in 161 Python files across 57 client repositories.

Each Android app must have an Android manifest file. It is one of the most important configuration files manually written by developers. In addition to various configuration parameters required to run an app, it also contains configuration parameters which are used to implement security, compatibility, and accessibility of an app. Any mistakes in writing the manifest file can cause serious implications in terms of security, reliability, and availability of an app. In this paper, we study and report different types of mistakes committed by developers in writing Android manifest files. The study was performed on 13,483 real-world Android apps. We also present an open source rule-based static analysis tool which detects developer mistakes in the manifest file. The tool generates a warning message if it detects any misconfigurations in the manifest file. We used the tool to perform the empirical study and it generated total 59,547 configuration errors in 11,110 apps. Only 2,373 apps, among studied apps, do not have any configuration errors.