An Empirical Study of Flaky Tests in JavaScript

TL;DR

This paper empirically investigates flaky tests in JavaScript projects, identifying main causes such as concurrency issues, OS-specific problems, and network instability, and analyzing common fixing strategies used by developers.

Contribution

It provides the first large-scale empirical analysis of flaky tests in JavaScript, highlighting key causes and developer responses.

Findings

Concurrency issues are the leading cause of flaky tests.

Most flaky tests (>80%) are fixed to eliminate flakiness.

Developers often skip, quarantine, or remove flaky tests.

Abstract

Flaky tests (tests with non-deterministic outcomes) can be problematic for testing efficiency and software reliability. Flaky tests in test suites can also significantly delay software releases. There have been several studies that attempt to quantify the impact of test flakiness in different programming languages (e.g., Java and Python) and application domains (e.g., mobile and GUI-based). In this paper, we conduct an empirical study of the state of flaky tests in JavaScript. We investigate two aspects of flaky tests in JavaScript projects: the main causes of flaky tests in these projects and common fixing strategies. By analysing 452 commits from large, top-scoring JavaScript projects from GitHub, we found that flakiness caused by concurrency-related issues (e.g., async wait, race conditions or deadlocks) is the most dominant reason for test flakiness. The other top causes of flaky tests are operating system-specific (e.g., features that work on specific OS or OS versions) and network stability (e.g., internet availability or bad socket management). In terms of how flaky tests are dealt with, the majority of those flaky tests (>80%) are fixed to eliminate flaky behaviour and developers sometimes skip, quarantine or remove flaky tests.