In software engineering, flaky tests are tests that exhibit inconsistent behavior, meaning they produce different outputs when executed multiple times under the same conditions. This behavior causes problems during regression testing, where each failure is supposed to indicate a bug introduced by the latest revision to the code base. A common strategy to detect flaky tests is Rerun, which executes each test repeatedly under the same conditions. The test is marked as flaky if both passing and failing results are observed. However, since flaky tests often only rarely fail while passing most times, Rerun is inefficient as it may take many runs to detect a test as flaky. We present a more efficient approach that focuses on detecting concurrency-related flakiness by limiting computing resources through Docker. Besides trying to detect flaky tests more quickly, we also examine how the limitation affects previously stable tests. As we aim to detect those tests that are most likely to cause problems in practice, flagging stable tests as flaky is undesirable as it may divert developers’ attention away from the more critical cases of flakiness. We achieve promising results as our approach reduces the number of runs needed to detect flakiness by almost 80%. When looking at absolute run time, we can provide a speedup of about 50%. However, we also observe that some previously stable tests fail under resource limitations. We find that clearly differentiating between flaky and stable tests proves challenging.     «

In software engineering, flaky tests are tests that exhibit inconsistent behavior, meaning they produce different outputs when executed multiple times under the same conditions. This behavior causes problems during regression testing, where each failure is supposed to indicate a bug introduced by the latest revision to the code base. A common strategy to detect flaky tests is Rerun, which executes each test repeatedly under the same conditions. The test is marked as flaky if both passing an...     »

Flaky Tests sind Tests, welches inkonsistentes Verhalten zeigen. Obwohl diese Test mehrfach unter den gleichen Bedingungen ausgeführt werden, zeigen sie unterschiedliche Ergebnisse. Dieses Verhalten führt zu Problemen bei Regression Testing, bei welchem jeder Fehlschlag eines Tests einen Bug anzeigen soll. Eine verbreitete Strategie, um flaky Tests zu erkennen, ist Rerun, welches jeden Test mehrfach unter den gleichen Bedingungen ausführt. Falls sowohl erfolgreiche als auch fehlerhafte Ausführungen für einen Test beobachtet werden, wird dieser als flaky markiert. Da die Wahrscheinlichkeit eines flaky Fehlschlages oft gering ist, kann diese Strategie recht ineffizient sein. Wir präsentieren einen effizienteren Ansatz, welcher durch das Limitieren von Ressourcen via Docker Nebenläufigkeit-bezogene Flakiness erkennen kann. Während wir versuchen, flaky Tests schnell zu erkennen, untersuchen wir ebenfalls, wie sich die Limitierung auf bis dato stabile Tests auswirkt. Da wir versuchen, praxisrelevante Flakiness aufzudecken, wäre ein markieren dieser stabilen Tests ungewünscht, da sie die Aufmerksamkeit der Entwickler von den kritischeren Fällen von Flakiness ablenken. Wir erhalten versprechende Resultate und können die Anzahl an Ausführungen zur Erkennung von Flakiness um ca. 80% reduzieren. Wenn man die absolute Laufzeit bis zur Erkennung betrachtet, erreichen wir eine Beschleunigung von ungefähr 50%. Allerdings sehen wir auch, dass einige stabile Tests unter Ressourcen Limitierung als flaky markiert werden. Wir kommen zu dem Schluss, dass ein klares Trennen zwischen flaky Tests und stabilen Tests schwierig ist.     «

Flaky Tests sind Tests, welches inkonsistentes Verhalten zeigen. Obwohl diese Test mehrfach unter den gleichen Bedingungen ausgeführt werden, zeigen sie unterschiedliche Ergebnisse. Dieses Verhalten führt zu Problemen bei Regression Testing, bei welchem jeder Fehlschlag eines Tests einen Bug anzeigen soll. Eine verbreitete Strategie, um flaky Tests zu erkennen, ist Rerun, welches jeden Test mehrfach unter den gleichen Bedingungen ausführt. Falls sowohl erfolgreiche als auch fehlerhafte Ausfü...     »