Autofixture: Discusión del enfoque de dependencia sustitutiva

Actualmente, el proyecto AutoNSubstitute depende de NSubstitute 1.5 . Sin embargo, la integración actual adolece de importantes problemas y limitaciones (consulte los números 720, 592, 707 y 653). Hay una forma de solucionarlos, sin embargo, necesitamos la API que apareció solo en NSubstitute 2.0.2 . Por lo tanto, debemos decidir cómo procederemos con esta biblioteca de adhesivos.

Forma 1: mantener un solo proyecto AutoNSubstitute

De esta manera continuamos con el proyecto actual AutoNSubstitute pero aumentamos la dependencia de NSubstitute a 2.0.2 . Introduciremos este cambio solo en la versión 4 y lo describiremos en la página Cambios importantes, por lo que no debería ser un problema.

__Pros: __

• Tendremos dos proyectos menos que respaldar (pegamento + pruebas) 😉
• Menos confusión. Necesitamos una versión nunca de lib para realizar la corrección de errores y cambiar el comportamiento (admite genéricos). Si implementamos eso solo en v2, puede resultar bastante confuso que para diferentes bibliotecas de pegamento el comportamiento sea diferente. Hasta donde yo sé, actualmente todas las versiones de una biblioteca de pegamento ofrecen la misma funcionalidad.

Forma 2: crea el proyecto AutoNSubstitute2

Por lo general, seguimos este camino cuando queríamos admitir otra versión de la biblioteca. Sin embargo, AFAIK en esos casos, la presencia del proyecto fue causada por los cambios importantes en lugar de la limitación de la funcionalidad (si lo veo claramente).

__Pros: __

• Seguimos apoyando todas las bibliotecas NSubstitute
• Sin cambios importantes para el NSubstitute original, por lo que sería más fácil consumir v4 (será posible migrar la solución paso a paso). Los usuarios podrán elegir cuándo quieren cambiar a NSubstitute 2 y una nueva biblioteca de pegamentos.

__Contras:__

• La biblioteca AutoNSubstitute sigue siendo compatible con NSubstitute 2.0.0 , por lo que sería un poco complicado tener dos versiones compatibles de la biblioteca de pegamento. Por supuesto, podríamos establecer artificialmente un límite para AutoNSubstitute v1, pero esa limitación será una pequeña mentira ya que todo binario está bien 😞

Personalmente, no tengo una opinión sólida aquí porque veo un valor en ambos enfoques. Sin embargo, si me veo obligado a elegir, preferiría la forma 1 porque es más fácil y NSubstitute 2 no tiene cambios importantes, por lo que no sería un problema migrar a ella.

@ AutoFixture / core ¿Qué opinas? ;-)