Software testing assures that code changes do not adversely affect existing functionality. However, a test case can be flaky, i.e., passing and failing across executions, even for the same version of the source code. Flaky test cases introduce overhead to software development as they can lead to unnecessary attempts to debug production or testing code. Besides rerunning test cases multiple times, which is time-consuming and computationally expensive, flaky test cases can be predicted using machine learning (ML) models, thus reducing the wasted cost of re-running and debugging these test cases. However, the state-of-the-art ML-based flaky test case predictors rely on pre-defined sets of features that are either project-specific, i.e., inapplicable to other projects, or require access to production code, which is not always available to software test engineers. Moreover, given the non-deterministic behavior of flaky test cases, it can be challenging to determine a complete set of features that could potentially be associated with test flakiness. Therefore, in this paper, we propose Flakify, a black-box, language model-based predictor for flaky test cases. Flakify relies exclusively on the source code of test cases, thus not requiring to (a) access to production code (black-box), (b) rerun test cases, (c) pre-define features. To this end, we employed CodeBERT, a pre-trained language model, and fine-tuned it to predict flaky test cases using the source code of test cases. We evaluated Flakify on two publicly available datasets (FlakeFlagger and IDoFT) for flaky test cases and compared our technique with the FlakeFlagger approach, the best state-of-the-art ML-based, white-box predictor for flaky test cases, using two different evaluation procedures: (1) cross-validation and (2) per-project validation, i.e., prediction on new projects. Flakify achieved F1-scores of 79% and 73% on the FlakeFlagger dataset using cross-validation and per-project validation, respectively. Similarly, Flakify achieved F1-scores of 98% and 89% on the IDoFT dataset using the two validation procedures, respectively. Further, Flakify surpassed FlakeFlagger by 10 and 18 percentage points (pp) in terms of precision and recall, respectively, when evaluated on the FlakeFlagger dataset, thus reducing the cost bound to be wasted on unnecessarily debugging test cases and production code by the same percentages (corresponding to reduction rates of 25% and 64%). Flakify also achieved significantly higher prediction results when used to predict test cases on new projects, suggesting better generalizability over FlakeFlagger. Our results further show that a black-box version of FlakeFlagger is not a viable option for predicting flaky test cases.

Context: Tangled commits are changes to software that address multiple concerns at once. For researchers interested in bugs, tangled commits mean that they actually study not only bugs, but also other concerns irrelevant for the study of bugs. Objective: We want to improve our understanding of the prevalence of tangling and the types of changes that are tangled within bug fixing commits. Methods: We use a crowd sourcing approach for manual labeling to validate which changes contribute to bug fixes for each line in bug fixing commits. Each line is labeled by four participants. If at least three participants agree on the same label, we have consensus. Results: We estimate that between 17% and 32% of all changes in bug fixing commits modify the source code to fix the underlying problem. However, when we only consider changes to the production code files this ratio increases to 66% to 87%. We find that about 11% of lines are hard to label leading to active disagreements between participants. Due to confirmed tangling and the uncertainty in our data, we estimate that 3% to 47% of data is noisy without manual untangling, depending on the use case. Conclusion: Tangled commits have a high prevalence in bug fixes and can lead to a large amount of noise in the data. Prior research indicates that this noise may alter results. As researchers, we should be skeptics and assume that unvalidated data is likely very noisy, until proven otherwise.

Continuous Integration and Continuous Delivery (CI/CD) is a well-established practice that automatically builds, tests, packages, and deploys software systems. To adopt CI/CD, software developers need to configure their projects using dedicated YML configuration files. Mobile apps have distinct characteristics with respect to CI/CD practices, such as testing on various emulators and deploying to app stores. However, little is known about the challenges and added value of adopting CI/CD in mobile apps and how developers maintain such a practice. In this article, we conduct an empirical study on CI/CD practices in \(2{,}557\) Android apps adopting 4 popular CI/CD services, namely GitHub Actions, Travis CI, CircleCI, and GitLab CI/CD. We also compare our findings with those reported in prior research on general CI/CD practices to situate them within broader trends. We observe a lack of commonality and standardization across CI/CD services and Android apps, leading to complex YML configurations and associated maintenance efforts. We also observe that CI/CD configurations focus primarily on the build setup, with around half of the projects performing standard testing and only 9% incorporating deployment. In addition, we find that CI/CD configurations are changed bi-monthly on average, with frequent maintenance correlating with active issue tracking, project size/age, and community engagement. Our qualitative analysis of commits uncovered 11 themes in CI/CD maintenance activities, with over a third of the changes focusing on improving workflows and fixing build issues, whereas another third involves updating the build environment, tools, and dependencies. Our study emphasizes the necessity for automation and AI-powered tools to improve CI/CD processes for mobile apps and advocates creating adaptable open source tools to efficiently manage resources, especially in testing and deployment.

Image segmentation is a challenging problem in medical applications. Medical imaging has become an integral part of machine learning research, as it enables inspecting interior human body with no surgical intervention. Much research has been conducted to study brain segmentation. However, prior studies usually employ one-stage models to segment brain tissues, which could lead to a significant information loss. In this paper, we propose a multi-stage Generative Adversarial Network ( $GAN$ ) model to resolve existing issues of one-stage models. To do this, we apply a coarse-to-fine method to improve brain segmentation using a multi-stage $GAN$ . In the first stage, our model generates a coarse outline for both the background and brain tissues. Then, in the second stage, the model generates a refine outline for the white matter ( $WM$ ), gray matter ( $GM$ ), and cerebrospinal fluid ( $CSF$ ). We perform a fusion of the coarse and refine outlines to achieve high results. Despite using very limited data, we obtain an improved Dice Coefficient (DC) accuracy of up to 5% compared to one-stage models. We conclude that our model is more efficient and accurate in practice for brain segmentation of both infants and adults. In addition, we observe that our multi-stage model is 2.69–13.93 minutes faster than prior models. Moreover, our multi-stage model achieves higher performance with only a few-shot learning, in which only limited labeled data is available. Therefore, for medical images, our solution is applicable to a wide range of image segmentation applications for which convolution neural networks and one-stage methods have failed. This helps to advance the process of analyzing brain images, thus providing many advantages to the healthcare system, especially in critical health situations where urgent intervention is needed.