Flaky tests, that yield varying outcomes for an invariant codebase, hinder regression testing. If one is not aware that they behave non-deterministically, their outcome may incorrectly indicate new bugs or hide real faults. To prevent this and resolve their flakiness, flaky tests must be detected as such, which is generally costly. If the non-determinism of flaky tests occurs due to the test order, varying the test order allows an efficient detection. Otherwise, to identify Non-Order-Dependent (NOD) flakiness, tests are usually executed repeatedly to possibly detect differing results. We propose an approach that reduces the number of required executions by identifying the majority of all non-flaky tests beforehand. Previous studies have shown that dynamic program analysis already helps to fix flakiness by evaluating program traces to find root causes of flakiness. Consequently we suppose that function call traces can indicate the existence of flakiness and that the absence of certain functions can identify a test as non-flaky. First, we present different approaches to identify functions, whose execution is characteris- tic for test flakiness. Thereafter, we assess these approaches and the sets of functions they produce. Both manual and semi-automated approaches achieve promising results. Finally, we evaluate whether they help to reduce effort for NOD flakiness detection. While we can greatly reduce the number of necessary reruns for NOD flakiness detection, this does not save execution time as desired, as we mostly exclude small tests while generat- ing overhead costs for the function call tracing. In nearly half of all examined projects our approach performs better, otherwise, it misses some NOD flaky tests or leads to increased execution times. In conclusion, the introduced approach to detect flakiness is not generally recommendable but significantly better in certain cases.     «

Flaky tests, that yield varying outcomes for an invariant codebase, hinder regression testing. If one is not aware that they behave non-deterministically, their outcome may incorrectly indicate new bugs or hide real faults. To prevent this and resolve their flakiness, flaky tests must be detected as such, which is generally costly. If the non-determinism of flaky tests occurs due to the test order, varying the test order allows an efficient detection. Otherwise, to identify Non-Order-Dependent (...     »

Tests, die trotz unveränderter Codebasis inkonsistente Ergebnisse produzieren, werden flaky Tests genannt. Ist man sich deren nicht-deterministischem Verhaltens nicht bewusst, können sie Fehler verbergen oder fälschlicherweise neue Probleme vortäuschen. Um dies zu verhindern, müssen flaky Tests als solche erkannt werden, was meist kostspielig ist. Ist der Nicht-Determinismus von Tests auf deren Ausführungsreihenfolge zurückzuführen, ermöglicht das Variieren der Reihenfolge zwar eine effiziente Erkennung der Flakiness, nicht-reihenfolgeabhängige (NOD) flaky Tests müssen in der Regel allerdings vielfach ausgeführt werden, um abweichende Ergebnisse zu entdecken. Wir schlagen einen Ansatz vor, der die Anzahl der zur Erkennung von Flakiness erforderlichen Ausführungen reduziert, indem die Mehrheit aller nicht-flaky Tests im Voraus identifiziert werden. Frühere Studien haben gezeigt, dass dynamische Programmanalyse bereits bei der Behebung von Flakiness hilft, indem man Programmabläufe analysiert, um die zugrunde liegenden Ursachen von Flakiness zu identifizieren. Folglich nehmen wir an, dass das Auswerten von Funktionsaufrufen Flakiness aufzeigen könnte und dass das Fehlen bestimmter Funktionen einen Test als nicht flaky identifizieren kann. Zunächst stellen wir verschiedene Verfahren zur Identifizierung von Funktionen vor, deren Vorkommen charakteristisch für die Flakiness von Tests ist. Anschließend bewerten wir diese Ansätze und die dadurch erhaltenen Funktionen. Sowohl manuelle als auch halbautomatische Verfahren erzielen vielversprechende Ergebnisse. Schließlich prüfen wir, ob diese den Aufwand für die Erkennung von NOD-Flakiness reduzieren können. Während wir die Anzahl der benötigten Test-Ausführungen für die Erkennung von NOD-Flakiness stark reduzieren können, sparen wir keine Zeit, da wir größtenteils kleine Tests ausschließen und das Speichern der Funktionsaufrufe ebenfalls Zeit benötigt. Für fast die Hälfte aller untersuchten Projekte ist unser Ansatz besser, bei den restlichen werden entweder NOD flaky Tests übersehen oder mehr Zeit zur Erkennung benötigt. Zusammenfassend lässt sich sagen, dass der vorgestellte Ansatz zur Erkennung von Flakiness nicht generell empfehlenswert ist, in bestimmten Fällen allerdings deutliche Verbesserung birgt.     «

Tests, die trotz unveränderter Codebasis inkonsistente Ergebnisse produzieren, werden flaky Tests genannt. Ist man sich deren nicht-deterministischem Verhaltens nicht bewusst, können sie Fehler verbergen oder fälschlicherweise neue Probleme vortäuschen. Um dies zu verhindern, müssen flaky Tests als solche erkannt werden, was meist kostspielig ist. Ist der Nicht-Determinismus von Tests auf deren Ausführungsreihenfolge zurückzuführen, ermöglicht das Variieren der Reihenfolge zwar eine effiziente...     »