FluentAssertions 8.10 : Améliorations de la qualité de vie pour l'équivalence (Null-as-Empty, meilleurs diagnostics, correspondance non ordonnée plus rapide)
FluentAssertions 8.10 semble modeste sur le papier, mais il cible exactement l'endroit où la plupart des suites de tests rencontrent des difficultés : les comparaisons d'équivalence et les diagnostics sur lesquels vous vous fiez lorsqu'elles échouent. Si vous utilisez ÊtreÉquivalentÀ lourdement (DTOs, contrats d'API, graphes d'objets imbriqués), ces changements réduisent le bruit, améliorent la lisibilité des échecs et accélèrent les cas lents.
Voici les quatre points forts et ce qu'ils changent dans la rédaction de tests au quotidien.
1) #3202 — Ajouter les méthodes `ComparingNullCollectionsAsEmpty` et `ComparingNullStringsAsEmpty` à `BeEquivalentTo`
Qu'est-ce qui a changé
FluentAssertions 8.10 ajoute deux nouvelles options d'équivalence, donc null Les collections correspondent vide collections, et null les chaînes peuvent correspondre vide chaînes.
ComparerLesChaînesNullCommeVides
Pourquoi c'est important
Dans de nombreux systèmes, la distinction entre null et vide n'a pas de sens. Les API omettent des champs, les sérialiseurs produisent des valeurs nulles, et les couches de mappage peuvent retourner des collections nulles même lorsque la logique métier les traite comme vides. Ces décalages créaient auparavant des tests fragiles ou forçaient une pré-normalisation.
Détail clé : graphes d'objets symétriques + imbriqués
Le comportement est symétrique (fonctionne de chaque côté de la comparaison) et il s'applique également à l'intérieur graphes d'objets imbriqués. Si une propriété imbriquée est nulle d'un côté et vide de l'autre, elle peut toujours correspondre lorsque l'option est activée.
2) #3203 — Inclure l'index d'origine dans les messages d'erreur relatifs aux éléments superflus
Qu'est-ce qui a changé
Les échecs d'équivalence pour les collections avec des éléments supplémentaires sont désormais plus exploitables. Les messages d'échec incluent les index original de chaque élément superflu dans le sujet.
Pourquoi c'est important
Lorsque l'ordre est ignoré et que les règles de correspondance sont complexes, les erreurs “ élément supplémentaire ” sont parmi les plus longues à déboguer. Avec l'index d'origine inclus, vous pouvez accéder directement à l'élément problématique, ce qui est particulièrement utile pour les grandes collections produites par des pipelines.
Impact pratique
- Diagnostic plus rapide de “ pourquoi y a-t-il un article supplémentaire ? ”
- Corrélation plus facile avec la logique LINQ/filtrage/jointure en amont
- Moins de temps d'impression de collections entières dans les journaux
3) #3188 — Accélération significative de la fonction `BeEquivalentTo` pour les grandes collections non ordonnées
Qu'est-ce qui a changé
Les performances sont améliorées pour les comparaisons d'équivalences non ordonnées (surtout avec SansOrdreStrict()) sur de grandes collections.
Pourquoi c'est important
Les grandes comparaisons non ordonnées sont une source fréquente de tests lents. Le gain principal provient du remplacement de la mise en correspondance coûteuse basée sur les permutations par une approche plus évolutive. stratégie gloutonne, plus les réductions d'allocation et les optimisations de simulation. Effet net : moins de temps d'attente pour les suites gourmandes en équivalences et moins de plaintes du type “ c'est trop lent pour fonctionner localement ”.
Impact pratique
- Comparaisons non ordonnées plus rapides sur de grandes collections
- Meilleure scalabilité à mesure que les ensembles de données augmentent
- Coûts généraux inférieurs grâce à moins d'allocations et moins de retour arrière
4) #3187 — Génère une erreur descriptive en cas d'échec lorsque des règles basées sur le chemin sont utilisées avec des types à sémantique de valeur
Qu'est-ce qui a changé
FluentAssertions corrige un cas limite d'équivalence déroutant : les règles basées sur les chemins comme Incluant() et Exclure() que des membres ciblés de types sémantiques de valeur ont été précédemment ignorés silencieusement.
Pourquoi c'est important
Les ignorés silencieux sont dangereux dans les tests : vous pensez avoir contraint la comparaison, mais la règle ne s'est jamais appliquée. Avec la version 8.10, ces cas échouent désormais explicitement avec une erreur claire expliquant pourquoi la règle ne s'applique pas et comment la résoudre. C'est un gain en termes de correction, en particulier pour les équipes qui s'appuient sur la configuration basée sur les chemins pour que les assertions restent ciblées.
Impact pratique
- Fini les surprises silencieuses de “la règle ne s'appliquait pas”
- Commentaires plus clairs lorsque la configuration est invalide
- Règles d'équivalence plus fiables dans de grandes suites
Que faire ensuite
Si vous mettez à niveau vers FluentAssertions 8.10, voici une liste de contrôle rapide :
- Si votre domaine traite les valeurs manquantes comme vides, envisagez d'activer les options null-as-empty.
- Si vous comparez de grandes collections sans ordre strict, attendez-vous à des exécutions plus rapides et à moins de ralentissements de la suite de tests.
- Si vous utilisez beaucoup de règles basées sur les chemins, surveillez les erreurs de configuration nouvellement apparues (qui étaient auparavant ignorées).
- Réexécutez les tests qui impliquent beaucoup d'équivalences et confirmez que les échecs sont maintenant plus faciles à diagnostiquer.
Si votre suite de tests s'appuie sur ÊtreÉquivalentÀ, FluentAssertions 8.10 est une mise à niveau à faible risque et à fort impact : moins d'échecs fragiles, des diagnostics plus clairs, des comparaisons non ordonnées plus rapides et une correction plus stricte des règles de configuration.
FAQ
Le traitement de null en tant que vide s'applique-t-il uniquement au niveau supérieur ?
Non. Les nouvelles options s'appliquent également à l'intérieur des graphes d'objets, de sorte que les propriétés imbriquées en bénéficient également.
La comparaison null-vide est-elle unidirectionnelle ?
Non, ça fonctionne symétriquement des deux côtés de la comparaison.
Les diagnostics d'index non pertinents améliorés modifieront-ils le comportement des assertions ?
Non. Il s'agit d'une amélioration des diagnostics. L'assertion échoue toujours pour la même raison ; le message d'erreur est simplement plus exploitable.
Qu'est-ce qui a changé en ce qui concerne les performances des collections non ordonnées ?
Les comparaisons non ordonnées (par exemple, en utilisant WithoutStrictOrdering) sont significativement plus rapides sur de grandes collections grâce à une stratégie de correspondance plus évolutive et à plusieurs optimisations d'allocation/exécution à sec.
Pourquoi les règles basées sur les chemins échouent-elles maintenant pour les types sémantiques de valeur ?
Car ces règles ne s'appliquent pas aux types à sémantique de valeur de la manière attendue par la plupart des gens. Au lieu d'ignorer silencieusement la règle, FluentAssertions échoue désormais avec une erreur descriptive afin que vous puissiez corriger explicitement la configuration.