Autofixture: Discussion sur l'approche de la dépendance de substitution

Actuellement, le projet AutoNSubstitute dépend de NSubstitute 1.5 . Cependant, l'intégration actuelle souffre de problèmes et de limitations importants (voir #720, #592, #707 et #653). Il existe un moyen de les corriger, mais nous avons besoin de l'API qui est apparue dans NSubstitute 2.0.2 uniquement. Par conséquent, nous devons décider de la manière dont nous allons procéder avec cette bibliothèque de colle.

Voie 1 - Gardez un seul projet AutoNSubstitute

De cette façon, nous continuons avec le projet AutoNSubstitute actuel mais augmentons la dépendance de NSubstitute à 2.0.2 . Nous introduirons ce changement dans la v4 uniquement et le décrirons sur la page Breaking Changes, donc cela ne devrait pas être un problème.

__Avantages:__

• Nous aurons deux projets de moins à soutenir (colle + tests)
• Moins de confusion. Nous avons besoin d'une version Never de lib pour effectuer la correction de bogue et changer le comportement (support génériques). Si nous implémentons cela uniquement dans la v2, il peut être assez déroutant que pour différentes bibliothèques de colle, le comportement soit différent. Pour autant que je sache, actuellement toutes les versions d'une bibliothèque de colle offrent la même fonctionnalité.

Façon 2 - Créez le projet AutoNSubstitute2

Habituellement, nous avons suivi cette voie lorsque nous voulions prendre en charge une autre version de la bibliothèque. Cependant, AFAIK dans ce cas, la présence du projet a été causée par les changements de rupture plutôt que par la limitation des fonctionnalités (si je vois cela clairement).

__Avantages:__

• Nous continuons à soutenir toutes les bibliothèques NSubstitute
• Pas de changements de rupture pour le NSubstitute d'origine, il serait donc plus facile de consommer la v4 (il sera possible de migrer la solution étape par étape). Les utilisateurs auront la possibilité de choisir quand ils souhaitent passer à NSubstitute 2 et à une nouvelle bibliothèque de colle.

__Les inconvénients:__

• La bibliothèque AutoNSubstitute est toujours compatible avec NSubstitute 2.0.0 , ce serait donc un peu compliqué d'avoir deux versions compatibles de la bibliothèque glue. Bien sûr, nous pourrions fixer artificiellement un plafond pour AutoNSSubstitute v1, mais cette limitation sera un petit mensonge car tout va bien en binaire

Personnellement, je n'ai pas d'opinion tranchée ici car je vois une valeur dans les deux approches. Cependant, si je suis obligé de choisir, je préférerais la voie 1 car c'est plus facile et NSubstitute 2 n'a pas de changements de rupture, donc ce ne serait pas un problème de migrer vers elle.

@AutoFixture/core Qu'en pensez-vous ? ;-)