Solución de problemas

Cada entrada parte de lo que ves. En todos los casos, -v escribe cada decisión y su motivo en stderr; ese registro responde a la mayoría de las preguntas y es lo que debes enviarnos.

td affected --base origin/main -v

Se ejecutó todo el proyecto de pruebas

Busca el proyecto en la salida: el motivo aparece a su lado. Las causas habituales son un archivo que afecta a toda la compilación, un archivo que no es de C# dentro del proyecto, un global using o un tipo que se encuentra por reflexión. Qué lo ejecuta todo los enumera todos. En el registro de -v, una línea como affects whole project: True nombra el archivo.

No se usó ningún mapa de cobertura

Sin un mapa, la selección rastrea nombres, lo que es más amplio. El registro indica por qué no lo había:

No coverage maps within 50 commits before the merge base: no se ha registrado nada recientemente en la rama predeterminada. Registra un mapa en cada push a ella; el modo record de la acción lo hace.
Ignoring the coverage map of … which is not an ancestor of the base: el mapa procede de otra rama, o de antes de un force push o de una rama de larga duración. Vuelve a registrar en la rama predeterminada o aumenta --max-map-age.
--maps-dir … does not exist: la carpeta con los mapas no se restauró antes de la ejecución.
En GitHub Actions, el job necesita el permiso actions: read para listar las entradas de caché que contienen los mapas.

No se encuentra el commit base

TestDetta compara tu rama con la merge base, así que necesita el historial de ambas. La acción se detiene con:

TestDetta compares with a base commit and needs the full history. Use actions/checkout with fetch-depth: 0.

Haz el checkout con fetch-depth: 0. En otros sistemas de CI, desactiva los clones superficiales y descarga la rama de destino con un refspec explícito, como se muestra para cada sistema en otros sistemas de CI.

Se omitieron menos pruebas de lo esperado

El mapa es anterior a la merge base y entretanto cambió un archivo de compilación o de configuración: los proyectos afectados se ejecutan completos. --drift-fallback name los reduce en su lugar por nombre.
Se selecciona una clase de prueba que no toca el cambio. El rastreo por nombre es prudente: una clase que nombra el tipo modificado se selecciona aunque la cobertura la hubiera descartado. Una línea de registro como is not in the coverage map of … Record the map again significa que el mapa está desactualizado para ese proyecto.
Cambió un helper central. El código que ejecutan la mayoría de las pruebas, como una clase base compartida o un serializador, selecciona la mayoría de las pruebas. Es lo correcto.

El filtro no coincidió con ninguna prueba

Cuando el filtro de un proyecto no selecciona ninguna prueba, TestDetta vuelve a ejecutar el proyecto sin el filtro y registra The filter for … matched no test; running it unfiltered. No se pasa nada por alto, pero es un error por nuestra parte: envíanos el registro de -v.

Squash merges, rebases y force pushes

Los mapas se registran para los commits de la rama predeterminada, y una pull request encuentra el más reciente en su merge base o antes. Un squash merge o un rebase crea commits nuevos en la rama predeterminada; el siguiente push registra un mapa para ellos y, hasta entonces, las pull requests usan el mapa anterior a través del drift bridge. Un force push a la rama de una pull request no cambia nada: la merge base se vuelve a calcular.

Pull requests desde forks

Los sistemas de CI no pasan secretos a las pull requests desde forks. Los repositorios públicos no necesitan licencia, así que para ellos no cambia nada. En un repositorio privado, una ejecución sin licencia ejecuta todas las pruebas, como lo haría sin TestDetta.

Preguntas

¿Es completa la cobertura de código de una ejecución seleccionada?

No. Una ejecución que omite pruebas produce una cobertura parcial. Publica la cobertura de las ejecuciones completas en la rama predeterminada; allí el registro ejecuta todas las pruebas.

¿Se pueden reintentar las pruebas?

Sí, con la opción de reintento de tu propio framework: todo lo que va después de -- se pasa a dotnet test sin cambios.

¿Se pueden repartir las pruebas seleccionadas entre jobs en paralelo?

td affected --format commands imprime un comando dotnet test por proyecto de pruebas, con su filtro. Reparte las líneas entre tus jobs.