Cómo decide

TestDetta reduce la selección paso a paso, y solo donde tiene pruebas de ello. Todo lo que no puede rastrear recurre a ejecutar más.

Seleccionar más, nunca menos

Una prueba pasada por alto es un error; una prueba de más solo cuesta tiempo de CI. Todas las reglas siguientes se derivan de eso. Cuando el análisis no está seguro de si un cambio afecta a un proyecto o a una clase, lo trata como afectado, y el motivo aparece en la salida.

Los cinco pasos

1. Proyectos

Los archivos modificados se asignan a sus proyectos y se siguen a través de las ProjectReference hasta cada proyecto que depende de ellos. Los archivos que afectan a toda la compilación, como Directory.Build.props, global.json y .editorconfig, afectan a todos los proyectos que están por debajo de ellos.

2. Símbolos

En los archivos de C#, se comparan los árboles de sintaxis antiguo y nuevo. Los cambios en comentarios y espacios en blanco no seleccionan nada; en los demás casos, TestDetta sabe qué tipos y miembros cambiaron.

3. Cobertura

Tras td record, un mapa de qué clase de prueba ejecutó qué método, registrado en el commit base, da directamente las clases de prueba de los métodos, propiedades y constructores modificados.

4. Nombres

Lo que la cobertura no puede ver, como el código nuevo, los campos y las constantes, se rastrea por nombre a través del código fuente hasta llegar a clases de prueba o a código que el mapa de cobertura conoce.

5. Alternativas seguras

Se ejecuta un proyecto de pruebas completo cuando un cambio no se puede rastrear:

• archivos que no son de C# dentro de un proyecto, como appsettings.json, el .csproj o un .resx;
• global usings y atributos de ensamblado;
• tipos que un framework descubre por reflexión, como controladores, manejadores de mensajes y configuraciones de EF.

La autocomprobación del filtro

TestDetta ejecuta un proyecto seleccionado con un filtro sobre sus clases de prueba. Un filtro que no coincide con ninguna prueba se trata como un error de TestDetta: el proyecto se vuelve a ejecutar sin él.

Mapas de cobertura

td record ejecuta todas las pruebas con cobertura y escribe un mapa por proyecto de pruebas. Lo ideal es registrar los mapas en la merge base de tu rama, y en CI se registra uno por cada commit de la rama predeterminada.

Mapas más antiguos y el drift bridge

Un mapa registrado hasta 50 commits antes de la merge base se sigue usando (--max-map-age, predeterminado 50; 0 usa solo un mapa registrado en la merge base). El código modificado entretanto podría haber creado llamadas que el mapa no conoce, así que TestDetta también selecciona las clases que ejecutaron cualquier miembro modificado desde entonces que pueda llegar a tu cambio, y rastrea el código nuevo por nombre.

Cuando algo intermedio no se puede describir en términos de miembros, como un archivo de compilación o appsettings.json, los proyectos de pruebas afectados se ejecutan completos. --drift-fallback name decide en su lugar por nombre, como sin mapa: más rápido, pero ciego a las llamadas conectadas mediante configuración o reflexión.

Sin mapa

Las primeras pull requests tras la configuración, o las que están muy atrasadas, no encuentran ningún mapa a su alcance. TestDetta selecciona entonces solo por nombre, lo cual es seguro pero selecciona más, y lo indica en su registro. La selección se vuelve precisa en cuanto td record se ha ejecutado en la rama predeterminada.

Ver el porqué

td affected y td test --dry-run muestran cada proyecto de pruebas afectado con el motivo por el que se ejecuta filtrado, completo o no se ejecuta; td affected --format json añade la decisión de cada clase de prueba. -v escribe cada decisión en stderr, por ejemplo por qué un proyecto se vio afectado o qué cambio ejecutó una clase.

$ td test --dry-run --base origin/main
td: 1 changed file(s), 2 affected test project(s).
Tests to run:
  filtered tests/Shop.Tests/Shop.Tests.csproj  (3 of 41 test class(es) run or reference the changed code)
  skip     tests/Api.Tests/Api.Tests.csproj  (no test class runs or references the changed code)