English (United Kingdom)

https://curated-unify.zendy.io/wp-json/zendy-region/v1/featured_content/oa?rat=en

https://curated-unify.zendy.io/wp-json/zendy-region/v1/highlighted_journal/

Global: Zendy Plus annual

Presents the access of premium content as premium feature

Premium Content

Presents the keyphrase highlighting as premium feature

Keyphrase Highlighting

Presents the summarisation as premium feature

Summarisation

Insights

Presents the pdf analysis as premium feature

PDF Analysis

Presents the zaia usage as premium feature

ZAIA

Global: Zendy Plus monthly

Global: Zendy Tools annual

Global: Zendy Tools monthly

Global: Zendy Free Plan

Flaky tests are defined as tests that manifest non-deterministic behaviour bypassing and failing intermittently for the same version of the code. Thesetests cripple continuous integration with false alerts that waste developers'time and break their trust in regression testing. To mitigate the effects offlakiness, both researchers and industrial experts proposed strategies andtools to detect and isolate flaky tests. However, flaky tests are rarely fixedas developers struggle to localise and understand their causes. Additionally,developers working with large codebases often need to know the sources ofnon-determinism to preserve code quality, i.e., avoid introducing technicaldebt linked with non-deterministic behaviour, and to avoid introducing newflaky tests. To aid with these tasks, we propose re-targeting FaultLocalisation techniques to the flaky component localisation problem, i.e.,pinpointing program classes that cause the non-deterministic behaviour of flakytests. In particular, we employ Spectrum-Based Fault Localisation (SBFL), acoverage-based fault localisation technique commonly adopted for its simplicityand effectiveness. We also utilise other data sources, such as change historyand static code metrics, to further improve the localisation. Our results showthat augmenting SBFL with change and code metrics ranks flaky classes in thetop-1 and top-5 suggestions, in 26% and 47% of the cases. Overall, wesuccessfully reduced the average number of classes inspected to locate thefirst flaky class to 19% of the total number of classes covered by flaky tests.Our results also show that localisation methods are effective in majorflakiness categories, such as concurrency and asynchronous waits, indicatingtheir general ability to identify flaky components.

What Made This Test Flake? Pinpointing Classes Responsible for Test Flakiness