NSubstitute dependency approach discussion

[zvirja]

Currently the AutoNSubstitute project depends on NSubstitute 1.5. However, current integration suffers from significant issues and limitations (see #720, #592, #707 and #653). There is a way to fix them, however we need the API which appeared in NSubstitute 2.0.2 only. Therefore, we need to decide how we'll proceed with this glue library.

Way 1 - Keep single AutoNSubstitute project

With this way we continue with current AutoNSubstitute project but increase NSubstitute dependency to 2.0.2. We will introduce this change in v4 only and describe that on the Breaking Changes page, so that should not be an issue.

Pros:

• We'll have two less project to support (glue + tests) 😉
• Less confusion. We need a never version of lib to perform the bug fix and change the behavior (support generics). If we implement that in v2 only, it might be quite confusing that for different glue libraries the behavior is different. As far as I know, currently all the versions of a glue library offer the same functionality.

Way 2 - Create the AutoNSubstitute2 project

Usually we followed this way when we wanted to support yet another version of library. However, AFAIK in that cases presence of the project was caused by the breaking changes rather than functionality limitation (if I see that clearly).

Pros:

• We continue to support all the NSubstitute libraries
• No breaking changes for the original NSubstitute, so it would be easier to consume v4 (it will be possible to migrate solution step by step). Users will have ability to choose when they want to switch to NSubstitute 2 and a new glue library.

Cons:

• The AutoNSubstitute library is still compatible with NSubstitute 2.0.0, so it would a little mess to have two compatible versions of the glue library. Of course, we could artificially set a cap for AutoNSubstitute v1, but that limitation will be a small lie as binary everything is fine 😞

---

Personally, I don't have a strong opinion here because I see a value in both approaches. However, if I'm forced to choose, I'd prefer the way 1 because it's easier and NSubstitute 2 doesn't have breaking changes, so that would not be a problem to migrate to it.

@AutoFixture/core What do you think? ;-)

[moodmosaic]

Yes, the less stuff to maintain, the easier it can be to move forward. I'm voting for 1.

[cvbarros]

Vote for 1.

[zvirja]

Followed that approach in #832, so now we require NSubstitute 2 for our integration.