Einschränkungen
Wo TestDetta etwas nicht sehen kann, wählt es mehr aus. Diese Seite listet diese Stellen auf, damit Sie wissen, wann eine Auswahl breiter ist als nötig, sowie die wenigen Fälle, in denen ein handgeschriebenes Muster einen Test verbergen kann.
Test-Frameworks und Test Runner
Beide Test Runner von dotnet test werden unterstützt. Der Test Runner wird aus global.json gelesen ("test": { "runner": "Microsoft.Testing.Platform" }, erforderlich für xUnit v3 mit dem .NET 10 SDK).
Jedes Testprojekt wird im Verzeichnis der nächstgelegenen global.json auf gleicher oder höherer Ebene gebaut und ausgeführt, sodass eine Datei neben der Solution (src/global.json) genauso gilt wie für einen Entwickler an dieser Stelle. --dry-run gibt solche Befehle als (cd src && dotnet test ...) aus.
Aufzeichnung und Auswahl werden durchgängig getestet mit xUnit v2 (VSTest), xUnit v3 und TUnit (Microsoft.Testing.Platform) sowie MSTest und NUnit unter beiden Test Runnern, einschließlich Projekten, die die eigene Parallelisierung ihres Frameworks aktivieren.
Tests, die bei der Aufzeichnung fehlschlagen
Testklassen, die bei der Aufzeichnung fehlschlagen, werden immer ausgewählt, wenn ihr Projekt betroffen ist: Ein fehlschlagender Test bricht vorzeitig ab, daher ist seine Coverage unvollständig.
Wenn Tests fehlschlagen und kein TRX-Bericht angibt, welche (NUnit unter Microsoft.Testing.Platform ohne Microsoft.Testing.Extensions.TrxReport), wird die Map nicht verwendet und die Auswahl fällt auf Namen zurück.
Code, der einmal pro Prozess läuft
Caches, Lazy-Singletons und der Aufbau von EF-Modellen laufen einmal pro Testprozess und werden der ersten Testklasse zugerechnet, die sie auslöst. Änderungen an Code, der in einem statischen Konstruktor oder einem Cache-befüllenden Aufruf lief (ConcurrentDictionary.GetOrAdd, Lazy<T>.Value, LazyInitializer, ConditionalWeakTable, IMemoryCache.GetOrCreate), sowie an Konstruktoren und statischen Membern, die pro Aufzeichnungsprozess nur eine Testklasse ausgeführt hat, werden stattdessen anhand des Namens verfolgt.
Ein von Hand geschriebener Cache, etwa ein mit TryGetValue abgefragtes Dictionary, kann seine Nutzer weiterhin verbergen. Führen Sie die vollständige Testsuite weiterhin auf dem Standard-Branch aus; die Aufzeichnung tut genau das.
Projektdateien
Projektdateien werden von MSBuild ausgewertet (ein dotnet msbuild-Aufruf, zwischengespeichert in .testdetta/cache), und zwar für Referenzen, kompilierte und eingebettete Elemente, Assemblynamen und Ziel-Frameworks, in der Standardkonfiguration und ohne Restore.
- Elemente, die nur die Props eines Pakets oder nur eine
Release-Bedingung hinzufügen, werden nicht erkannt. - Ein Projekt, das MSBuild nicht auswerten kann, wird als XML gelesen, ebenso Importe.
- Eine geänderte Datei in einem Projektordner, die das Projekt nicht kompiliert, zählt als Änderung an diesem Projekt. Eine Datei außerhalb aller Projektordner wählt nichts aus; siehe ignorierte Dateien.
- Testprojekte werden auch an einem Namen der Form
*.Testsoder*.Testerkannt.
Was der Code nicht zeigen kann
TestDetta sieht Ihren Quellcode, Ihre Projektdateien und das, was Ihre Tests bei der Aufzeichnung ausgeführt haben. Nicht sehen kann es:
- Externe Dienste und Datenbanken. Eine Änderung in einem anderen System, etwa eine anderswo angewendete Schemamigration oder eine API, die Ihre Tests aufrufen, wählt hier nichts aus.
- Dateien, die zur Laufzeit von außerhalb der Projektordner gelesen werden, etwa gemeinsame Testdaten im Stammverzeichnis des Repositorys. Legen Sie sie in das Testprojekt; siehe ignorierte Dateien.
- Umgebung: Variablen, Rechnereinstellungen und installierte Tools, die sich zwischen Läufen unterscheiden.
Änderungen an Paketversionen werden erkannt: Eine PackageVersion-Änderung in Directory.Packages.props führt die Projekte aus, die das Paket referenzieren, und eine PackageReference-Änderung ist eine Änderung an der Projektdatei.
Präprozessorsymbole
C#-Dateien werden mit den tatsächlichen Präprozessorsymbolen jedes Ziel-Frameworks geparst, außerdem ohne Symbole und mit allen Symbolen, die ihre #if-Direktiven nennen, sodass Code unter jeder aktiven Bedingung erfasst wird.
Übersprungene Tests
Tests, die bei der Aufzeichnung einer Map übersprungen wurden, haben keine Coverage. Eine Klasse, deren Tests alle übersprungen wurden, wird auf einer anderen Plattform ausgewählt, auf der sie laufen könnte, und auf der Aufzeichnungsplattform übersprungen. Tests, die aus anderen Gründen übersprungen werden, etwa weil kein Docker-Daemon verfügbar ist, werden nur durch eine Aufzeichnung dort abgedeckt, wo die Tests laufen.
Source Generators
Von Source Generators geschriebener Code liegt nicht im Quellbaum. td record liest ihn aus den PDBs der aufgezeichneten Assemblys (portabel oder eingebettet) und behält die darin genannten Namen in der Map, sodass die Namensverfolgung generierte Aufrufer sieht. Assemblys, die ohne portables PDB gebaut wurden, liefern nichts.
F# und Visual Basic
F#- und Visual-Basic-Projekte sind Teil des Projektgraphen, ihr Code wird jedoch nicht analysiert: Ist eines davon betroffen, läuft alles, was davon abhängt, vollständig.