Limitaciones
Donde TestDetta no puede ver algo, selecciona más. Esta página enumera esos casos, para que sepas cuándo una selección es más amplia de lo necesario, y los pocos casos en los que un patrón escrito a mano puede ocultar una prueba.
Frameworks de pruebas y runners
Se admiten ambos runners de dotnet test. El runner se lee de global.json ("test": { "runner": "Microsoft.Testing.Platform" }, obligatorio para xUnit v3 con el SDK de .NET 10).
Cada proyecto de pruebas se compila y ejecuta en el directorio del global.json más cercano en su nivel o por encima, de modo que un archivo guardado junto a la solución (src/global.json) cuenta igual que para un desarrollador que trabaje ahí. --dry-run muestra esos comandos como (cd src && dotnet test ...).
El registro y la selección se prueban de extremo a extremo con xUnit v2 (VSTest), xUnit v3 y TUnit (Microsoft.Testing.Platform), y MSTest y NUnit con ambos runners, incluidos proyectos que activan la paralelización propia de su framework.
Pruebas que fallan durante el registro
Las clases de prueba que fallan durante el registro se seleccionan siempre que su proyecto se ve afectado: una prueba que falla se detiene antes de tiempo, así que su cobertura está incompleta.
Cuando fallan pruebas y ningún informe TRX indica cuáles (NUnit con Microsoft.Testing.Platform sin Microsoft.Testing.Extensions.TrxReport), el mapa no se usa y la selección recurre a los nombres.
Código que se ejecuta una vez por proceso
Las cachés, los singletons diferidos y la construcción del modelo de EF se ejecutan una vez por proceso de prueba y se atribuyen a la primera clase de prueba que los desencadena. Los cambios en código que se ejecutó dentro de un constructor estático o de una llamada que llena una caché (ConcurrentDictionary.GetOrAdd, Lazy<T>.Value, LazyInitializer, ConditionalWeakTable, IMemoryCache.GetOrCreate), y en constructores y miembros estáticos que solo una clase de prueba por proceso de registro ejecutó, se rastrean en su lugar por nombre.
Una caché escrita a mano, como un Dictionary consultado con TryGetValue, todavía puede ocultar a quienes la usan. Sigue ejecutando el conjunto completo en la rama predeterminada; el registro ya lo hace.
Archivos de proyecto
Los archivos de proyecto los evalúa MSBuild (una llamada a dotnet msbuild, almacenada en caché en .testdetta/cache) para obtener referencias, elementos compilados e incrustados, nombres de ensamblado y frameworks de destino, en la configuración predeterminada y sin restore.
- No se ven los elementos que solo añaden los props de un paquete o solo una condición
Release. - Un proyecto que MSBuild no puede evaluar se lee como XML, al igual que los imports.
- Un archivo modificado dentro de la carpeta de un proyecto que el proyecto no compila cuenta como un cambio en ese proyecto. Un archivo fuera de todas las carpetas de proyecto no selecciona nada; consulta archivos que se ignoran.
- Los proyectos de pruebas también se reconocen por un nombre
*.Testso*.Test.
Lo que el código no puede mostrar
TestDetta ve tu código fuente, tus archivos de proyecto y lo que ejecutaron tus pruebas durante el registro. No puede ver:
- Servicios externos y bases de datos. Un cambio en otro sistema, como una migración de esquema aplicada en otro lugar o una API a la que llaman tus pruebas, aquí no selecciona nada.
- Archivos leídos en tiempo de ejecución desde fuera de las carpetas de proyecto, como datos de prueba compartidos en la raíz del repositorio. Mantenlos dentro del proyecto de pruebas; consulta archivos que se ignoran.
- El entorno: variables, ajustes de la máquina y herramientas instaladas que difieren entre ejecuciones.
Los cambios de versión de los paquetes sí se ven: un cambio de PackageVersion en Directory.Packages.props ejecuta los proyectos que hacen referencia al paquete, y un cambio de PackageReference es un cambio en el archivo de proyecto.
Símbolos del preprocesador
Los archivos de C# se analizan con los símbolos de preprocesador reales de cada framework de destino, y también sin símbolos y con todos los símbolos que nombran sus #if, de modo que se ve el código bajo cualquier condición activa.
Pruebas omitidas
Las pruebas que se omitieron (skipped) mientras se registraba un mapa no tienen cobertura. Una clase cuyas pruebas se omitieron todas se selecciona en otra plataforma, donde puede ejecutarse, y se omite en la plataforma de registro. Las pruebas omitidas por otros motivos, como la falta de un daemon de Docker, solo quedan cubiertas si el registro se hace donde se ejecutan las pruebas.
Generadores de código fuente
El código escrito por generadores de código fuente no está en el árbol de código fuente. td record lo lee de los PDB de los ensamblados registrados (portables o incrustados) y guarda en el mapa los nombres que menciona, para que el rastreo por nombre vea a los llamadores generados. Los ensamblados compilados sin un PDB portable no aportan nada.
F# y Visual Basic
Los proyectos de F# y Visual Basic forman parte del grafo de proyectos, pero su código no se analiza: cuando uno se ve afectado, todo lo que depende de él se ejecuta completo.