Was alle Tests auslöst
Die meisten Änderungen wählen wenige Testklassen aus. Manche lassen sich nicht sicher eingrenzen, deshalb führt TestDetta dann ein ganzes Testprojekt aus oder alle Projekte unterhalb eines Ordners. Diese Seite listet sie alle auf, damit eine breite Auswahl nie überrascht.
Build-weite Dateien
Diese Dateien ändern, wie jedes Projekt unterhalb von ihnen gebaut wird. Eine Änderung an einer davon führt jedes Testprojekt in ihrem Ordner und darunter aus:
| Datei | Führt aus |
|---|---|
Directory.Build.props, Directory.Build.targets, Directory.Build.rsp | Jedes Testprojekt darunter |
Directory.Solution.props, Directory.Solution.targets | Jedes Testprojekt darunter |
global.json, NuGet.config, .editorconfig | Jedes Testprojekt darunter |
Directory.Packages.props, nur PackageVersion-Elemente geändert | Nur die Testprojekte, die ein geändertes Paket referenzieren, und die, die von ihnen abhängen |
Directory.Packages.props, alles andere (eine GlobalPackageReference, transitives Pinning, Eigenschaften) | Jedes Testprojekt darunter |
Änderungen, die ein ganzes Testprojekt ausführen
| Änderung | Warum sie sich nicht eingrenzen lässt |
|---|---|
Die Projektdatei oder eine von ihr importierte .props- oder .targets-Datei | Sie kann ändern, wie alles im Projekt gebaut wird. |
Jede Nicht-C#-Datei im Projekt, etwa appsettings.json, eine .resx oder eine Testdatendatei | Keine Coverage-Map sagt, wer sie liest. |
Ein global using oder ein Assembly-Attribut | Es gilt für jede Datei. |
| Eine C#-Änderung in Code, den keine Deklaration umfasst, etwa unter einer Präprozessorbedingung | Es gibt keinen Member, dem man folgen kann. |
| Ein geänderter Typ, den nichts beim Namen nennt, den ein Framework aber per Reflection finden könnte (Controller, Message-Handler, EF-Konfigurationen) | Namen und Coverage können nicht sagen, wer ihn findet. |
| Eine Änderung in einem F#- oder Visual-Basic-Projekt | Deren Code wird nicht analysiert. |
| Ein Projekt, das als Analyzer oder Source Generator verwendet wird | Es wirkt auf die Kompilierung, nicht auf Aufrufe. |
Jede dieser Änderungen führt außerdem jedes Testprojekt aus, das vom betroffenen abhängt.
Situationen mit Coverage-Maps
- Eine ältere Map und Build-Änderungen dazwischen. Ist die Map einige Commits älter als Ihre Merge-Base und hat sich dazwischen eine Build- oder Konfigurationsdatei geändert, laufen die betroffenen Testprojekte vollständig.
--drift-fallback nameentscheidet sie stattdessen anhand von Namen. Siehe die Drift-Bridge. - Jede Klasse ausgewählt. Ein Projekt, dessen Klassen alle ausgewählt sind, läuft ohne Filter.
- Ein Filter, der nichts trifft. Das Projekt läuft ohne Filter erneut, und TestDetta behandelt das als eigenen Fehler.
Gar keine Map führt nicht alles aus: Die Auswahl fällt auf die Namensverfolgung zurück, die breiter ist als die Coverage, aber dennoch eng.
Ignorierte Dateien
Eine geänderte Datei außerhalb aller Projektordner, etwa README.md, Dateien unter .github/ oder ein Skript im Stammverzeichnis des Repositorys, gehört zu keinem Projekt und wählt nichts aus. Sie erscheint in der Ausgabe als nicht zugeordnet.
Wenn Ihre Tests eine Datei lesen, die außerhalb aller Projektordner liegt, wählt eine Änderung daran sie nicht aus. Legen Sie solche Dateien in das Testprojekt oder führen Sie sie als dessen Items auf, zum Beispiel <None Include="..\..\testdata\**" CopyToOutputDirectory="PreserveNewest" />. Dann gehört die Datei zum Projekt, wo immer sie liegt, und eine Änderung oder ihr Löschen führt das Projekt aus.
Eine Ausnahme: Eine Quell- oder Build-Datei, die kein Projekt beansprucht (.cs, .fs, .vb, .props, .targets, .projitems), zählt als Build-Eingabe jedes Projekts, dessen Importe nicht vollständig aufgelöst werden konnten, sodass diese laufen.