FluentAssertions 8.10: Mejoras de calidad de vida en equivalencia (Nulo como vacío, mejores diagnósticos, coincidencia desordenada más rápida)
FluentAssertions 8.10 parece pequeño sobre el papel, pero apunta al lugar exacto donde la mayoría de los conjuntos de pruebas sienten dolor: las comparaciones de equivalencia y los diagnósticos en los que confías cuando fallan. Si usas SerEquivalenteA con (DTOs, contratos de API, grafos de objetos anidados), estos cambios reducen el ruido, mejoran la legibilidad de los fallos y aceleran los casos lentos.
A continuación se presentan los cuatro puntos clave y los cambios que implican en la redacción de pruebas diarias.
1) #3202 — Agregar ComparingNullCollectionsAsEmpty y ComparingNullStringsAsEmpty a BeEquivalentTo
¿Qué cambió?
FluentAssertions 8.10 agrega dos nuevas opciones de equivalencia así que null las colecciones coinciden vacío colecciones, y null las cadenas pueden coincidir vacío cadenas.
Comparando Cadenas Nulas como Vacías
Por qué esto importa
En muchos sistemas, nulo vs. vacío no es una distinción significativa. Las APIs omiten campos, los serializadores producen nulos y las capas de mapeo pueden devolver colecciones nulas incluso cuando la lógica de negocio las trata como vacías. Estas discrepancias solían crear pruebas frágiles o forzar una pre-normalización.
Detalle clave: grafos de objetos simétricos y anidados
El comportamiento es simétrico (funciona en ambos lados de la comparación) y también se aplica por dentro gráficos de objetos anidados. Si una propiedad anidada es nula en un lado y vacía en el otro, aún puede coincidir cuando la opción está habilitada.
2) #3203 — Incluir el índice original en los mensajes de error por elementos extraños
¿Qué cambió?
Las fallas de equivalencia para colecciones con elementos adicionales ahora son más procesables. Los mensajes de falla incluyen el índice original de cada elemento externo en el tema.
Por qué esto importa
Cuando se ignora el orden y las reglas de coincidencia son complejas, los fallos de “elemento extra” son de los que consumen más tiempo para depurar. Con el índice original incluido, puedes ir directamente al elemento problemático, lo cual es especialmente útil para colecciones grandes producidas por pipelines.
Impacto práctico
- Diagnóstico más rápido de “¿por qué hay un artículo adicional?”
- Correlación más sencilla con la lógica LINQ, de filtrado y de unión de nivel superior
- Menos tiempo imprimiendo colecciones completas en los registros
3) #3188 — Aumenta significativamente la velocidad de BeEquivalentTo para colecciones grandes no ordenadas
¿Qué cambió?
El rendimiento mejora para comparaciones de equivalencia no ordenadas (especialmente con SinOrdenEstricto()en colecciones grandes.
Por qué esto importa
Las comparaciones grandes y desordenadas son una fuente común de pruebas lentas. El principal beneficio proviene de reemplazar la coincidencia costosa basada en permutaciones con una más escalable estrategia codiciosa, además de reducciones en la asignación y optimizaciones de ejecución en seco. Efecto neto: menos tiempo esperando por suites con muchas equivalencias y menos quejas de “es demasiado lento para ejecutarlo localmente”.
Impacto práctico
- Comparaciones desordenadas más rápidas en colecciones grandes
- Mejor escalabilidad a medida que crecen los conjuntos de datos
- Menor sobrecarga por menos asignaciones y menos retrocesos
4) #3187 — Generar un error descriptivo cuando se utilizan reglas basadas en rutas en tipos con semántica de valores
¿Qué cambió?
FluentAssertions resuelve un caso límite de equivalencia confuso: reglas basadas en rutas como Incluir() y Excluir() que miembros de el objetivo tipos semánticos de valor fueron previamente ignorados silenciosamente.
Por qué esto importa
Los silencios automáticos en las pruebas son peligrosos: crees que has limitado la comparación, pero la regla nunca se aplicó. Con la versión 8.10, estos casos ahora fallan explícitamente con un error claro que explica por qué la regla no se aplica y cómo resolverlo. Eso es una victoria en cuanto a corrección, especialmente para equipos que dependen de la configuración basada en rutas para mantener las afirmaciones enfocadas.
Impacto práctico
- No más sorpresas silenciosas de “la regla no aplicaba”
- Retroalimentación más clara cuando la configuración no es válida
- Reglas de equivalencia más confiables en suites grandes
¿Qué hacer después?
Si estás actualizando a FluentAssertions 8.10, aquí tienes una lista rápida de verificación:
- Si tu dominio trata los valores faltantes como vacíos, considera habilitar las opciones de null-as-empty.
- Si comparas colecciones grandes sin un orden estricto, espera ejecuciones más rápidas y menos arrastre del conjunto de pruebas.
- Si usas reglas basadas en rutas intensivamente, ten cuidado con errores de configuración recién expuestos (que antes se ignoraban).
- Vuelve a ejecutar las pruebas con muchas equivalencias y confirma que los fallos son ahora más fáciles de diagnosticar.
Si tu conjunto de pruebas se inclina hacia SerEquivalenteA, FluentAssertions 8.10 es una actualización de bajo riesgo y alta eficiencia: menos fallos frágiles, diagnósticos más claros, comparaciones desordenadas más rápidas y mayor rigor en las reglas de configuración.
Preguntas frecuentes
¿La nulidad como vacío se aplica solo en el nivel superior?
No. Las nuevas opciones se aplican también dentro de los grafos de objetos, por lo que las propiedades anidadas también se benefician.
¿La comparación nulo-como-vacío es unidireccional?
No. Funciona simétricamente en ambos lados de la comparación.
¿Cambiarán los diagnósticos de índices externos mejorados el comportamiento de las aserciones?
No. Esto es una mejora de diagnóstico. La aserción aún falla por la misma razón; el mensaje de error es simplemente más útil.
¿Qué cambió en el rendimiento de las colecciones no ordenadas?
Las comparaciones no ordenadas (por ejemplo, usando WithoutStrictOrdering) son significativamente más rápidas en colecciones grandes debido a una estrategia de coincidencia más escalable y varias optimizaciones de asignación/ejecución de prueba.
¿Por qué las reglas basadas en rutas ahora fallan para los tipos semánticos de valor?
Porque esas reglas no se aplican a los tipos semánticos de valor de la manera que la mayoría de la gente espera. En lugar de ignorar silenciosamente la regla, FluentAssertions ahora falla con un error descriptivo para que pueda arreglar la configuración explícitamente.