Autofixture: Diskussion über den Ersatzabhängigkeitsansatz

Derzeit hängt das Projekt AutoNSubstitute von NSubstitute 1.5 ab . Die aktuelle Integration leidet jedoch unter erheblichen Problemen und Einschränkungen (siehe #720, #592, #707 und #653). Es gibt eine Möglichkeit, sie zu beheben, aber wir benötigen die API, die nur in NSubstitute 2.0.2 erschienen ist . Daher müssen wir entscheiden, wie wir mit dieser Leimbibliothek verfahren.

Weg 1 – Behalten Sie ein einzelnes AutoNSubstitute Projekt bei

Auf diese Weise fahren wir mit dem aktuellen AutoNSubstitute Projekt fort, erhöhen jedoch die NSubstitute-Abhängigkeit auf 2.0.2 . Wir werden diese Änderung nur in v4 einführen und auf der Seite „Breaking Changes“ beschreiben, sodass dies kein Problem sein sollte.

__Vorteile:__

• Wir werden zwei Projekte weniger zu unterstützen haben (Kleber + Tests) 😉
• Weniger Verwirrung. Wir benötigen eine Never-Version von lib, um die Fehlerbehebung durchzuführen und das Verhalten zu ändern (Unterstützung von Generika). Wenn wir das nur in v2 implementieren, kann es ziemlich verwirrend sein, dass das Verhalten für verschiedene Glue-Bibliotheken unterschiedlich ist. Soweit mir bekannt ist, bieten derzeit alle Versionen einer Glue-Bibliothek die gleiche Funktionalität.

Weg 2 – Erstellen Sie das AutoNSubstitute2 Projekt

Normalerweise sind wir diesem Weg gefolgt, wenn wir eine weitere Version der Bibliothek unterstützen wollten. Allerdings wurde AFAIK in diesen Fällen durch die Breaking Changes und nicht durch Funktionseinschränkungen verursacht (wenn ich das klar sehe).

__Vorteile:__

• Wir unterstützen weiterhin alle NSubstitute-Bibliotheken
• Keine grundlegenden Änderungen für das ursprüngliche NSubstitute, daher wäre es einfacher, v4 zu verwenden (es wird möglich sein, die Lösung Schritt für Schritt zu migrieren). Benutzer können wählen, wann sie zu NSubstitute 2 und einer neuen Glue-Bibliothek wechseln möchten.

__Nachteile:__

• Die AutoNSubstitute Bibliothek ist immer noch mit NSubstitute 2.0.0 kompatibel, daher wäre es ein bisschen durcheinander, zwei kompatible Versionen der Glue-Bibliothek zu haben. Natürlich könnten wir für AutoNSubstitute v1 künstlich eine Obergrenze festlegen, aber diese Einschränkung wird eine kleine Lüge sein, da binär alles in Ordnung ist 😞

Ich persönlich habe hier keine starke Meinung, weil ich in beiden Ansätzen einen Wert sehe. Wenn ich jedoch gezwungen bin, mich zu entscheiden, würde ich den Weg 1 bevorzugen, da er einfacher ist und NSubstitute 2 keine Breaking Changes hat, so dass die Migration kein Problem darstellen würde.

@AutoFixture/core Was denkst du? ;-)