Führen Sie nur die Tests aus, die Ihre Änderung brechen kann.
TestDetta liest Ihren Diff, verfolgt ihn über Projekte, Symbole und aufgezeichnete Coverage und führt nur die Testklassen aus, die die Änderung bemerken können. Ist es sich nicht sicher, führt es mehr aus, nie weniger.
$ td test --base main -- -f net10.0td: 1 changed file(s), 1 affected test project(s).Tests to run: filtered src/Spectre.Console.Tests/Spectre.Console.Tests.csproj (14 of 141 test class(es) run or reference the changed code, 0.6 s of 3.0 s (80% saved))Recorded test time: 0.6 s of 3.4 s (83% saved).Passed! - Failed: 0, Passed: 156, Total: 156 - Spectre.Console.Tests.dlltd summary: passed src/Spectre.Console.Tests/Spectre.Console.Tests.csproj (14 class(es), 4.6 s)1 project(s) run, 0 failed, 0 skipped.# eine echte Änderung an Spectre.Console: den ganzen Lauf ansehen
Gemessen an echtem Code, nicht an Demos
Wir ändern Member verbreiteter Open-Source-Bibliotheken für .NET einzeln und prüfen, dass jede fehlschlagende Testklasse eine ist, die TestDetta ausgewählt hat.
Eine Änderung an einem Member führte im Median 28% der Testklassen aus. Einen echten Lauf ansehen, vom Diff bis zur Job Summary →
Wie es entscheidet
Jeder Schritt grenzt die Auswahl nur ein, wenn er Belege dafür hat. Alles, was sich nicht nachverfolgen lässt, führt dazu, dass mehr ausgeführt wird.
Projekte
Geänderte Dateien werden Projekten zugeordnet und folgen den ProjectReferences. Build-weite Dateien wie Directory.Build.props betreffen alles unterhalb von ihnen.
Symbole
C#-Syntaxbäume werden verglichen, sodass Änderungen an Kommentaren und Leerraum nichts auswählen und TestDetta weiß, welche Member sich geändert haben.
Coverage
Eine auf Ihrem Standard-Branch aufgezeichnete Map gibt an, welche Testklasse welche Methode ausgeführt hat, sodass geänderte Methoden ihre Klassen direkt auswählen.
Namen
Neuer Code, Felder und Konstanten werden anhand ihres Namens durch den Quellcode verfolgt, bis sie Testklassen oder Code erreichen, den die Map kennt.
Fallbacks
Konfigurationsdateien, globale Usings, per Reflection gefundene Typen: Lässt sich eine Änderung nicht nachverfolgen, läuft das gesamte Testprojekt.
Selbstprüfungen
Ein Filter, der keinem Test entspricht, wird als Fehler in TestDetta behandelt, und das Projekt läuft ohne ihn erneut.
Zwei Schritte in GitHub Actions
Zeichnen Sie bei jedem Push auf Ihren Standard-Branch eine Coverage-Map auf. Pull Requests stellen die neueste Map wieder her und führen nur die betroffenen Tests aus, mit einer Job Summary, die angibt, warum jede Klasse ausgeführt oder übersprungen wurde.
Anleitung für GitHub Actions →
GitLab CI, Jenkins, Azure DevOps, Bitbucket →
- if: github.event_name == 'push'
uses: <owner>/testdetta@<sha>
with:
mode: record
- if: github.event_name == 'pull_request'
uses: <owner>/testdetta@<sha>
with:
mode: test
license: ${{ secrets.TESTDETTA_LICENSE }}
Für Teams, die sich keinen übersehenen Test leisten können
Ihr Code bleibt bei Ihnen
TestDetta läuft in Ihrer CI. Weder Quellcode noch Coverage noch Testergebnisse verlassen Ihre Rechner; die E-Mail-Adressen der Committer werden nur lokal gezählt.
Jedes Framework, das Sie verwenden
xUnit v2 und v3, NUnit, MSTest und TUnit, sowohl unter VSTest als auch unter Microsoft.Testing.Platform, einschließlich ihrer eigenen Parallelisierung.
Blockiert nie einen Build
Ohne gültige Lizenz laufen wie bisher alle Tests. Ein Lizenzproblem kostet CI-Zeit, nie einen roten Build.
Kostenlos für öffentliche Repositorys. 30 Tage kostenlos für private.
Danach $15 pro aktivem Committer und Monat. Für die Testphase ist keine Kreditkarte nötig.