Autofixture: NSubstitute 의존성 접근 논의

현재 AutoNSubstitute 프로젝트는 NSubstitute 1.5에 의존합니다. 그러나 현재 통합은 심각한 문제와 한계를 안고 있습니다(#720, #592, #707 및 #653 참조). 이를 고칠 수 있는 방법이 있지만 NSubstitute 2.0.2 에만 나타난 API가 필요합니다. 따라서 이 글루 라이브러리를 어떻게 진행할지 결정해야 합니다.

방법 1 - 단일 AutoNSubstitute 프로젝트 유지

이 방법으로 현재 AutoNSubstitute 프로젝트를 계속하지만 NSubstitute 종속성을 2.0.2 늘립니다. 이 변경 사항은 v4에서만 소개하고 주요 변경 사항 페이지에서 설명하므로 문제가 되지 않습니다.

__장점:__

• 지원해야 할 프로젝트가 두 개 줄어듭니다(접착제 + 테스트) 😉
• 혼란이 적습니다. 버그 수정을 수행하고 동작을 변경하려면 절대 버전의 lib가 필요합니다(제네릭 지원). v2에서만 구현하면 다른 글루 라이브러리의 동작이 다르다는 것이 상당히 혼란스러울 수 있습니다. 내가 아는 한 현재 모든 버전의 글루 라이브러리가 동일한 기능을 제공합니다.

방법 2 - AutoNSubstitute2 프로젝트 만들기

보통 우리는 또 다른 버전의 라이브러리를 지원하고 싶을 때 이 방법을 따랐습니다. 그러나 AFAIK 이 경우 프로젝트의 존재는 기능 제한이 아닌 주요 변경 사항으로 인해 발생했습니다(명확하게 보이는 경우).

__장점:__

• 우리는 모든 NSubstitute 라이브러리를 계속 지원합니다.
• 원래 NSubstitute에 대한 주요 변경 사항이 없으므로 v4를 사용하는 것이 더 쉬울 것입니다(솔루션을 단계별로 마이그레이션할 수 있음). 사용자는 NSubstitute 2와 새로운 글루 라이브러리로 언제 전환할지 선택할 수 있습니다.

__단점:__

• AutoNSubstitute 라이브러리는 여전히 NSubstitute 2.0.0 와 호환되므로 두 개의 호환 가능한 버전의 글루 라이브러리가 있으면 약간 엉망이 될 것입니다. 물론 AutoNSubstitute v1의 상한선을 인위적으로 설정할 수도 있지만 바이너리 모든 것이 정상이므로 그 제한은 작은 거짓말일 것입니다 😞

개인적으로 나는 두 접근 방식 모두에서 가치를 보기 때문에 여기에 대해 강한 의견을 갖고 있지 않습니다. 하지만 어쩔 수 없이 선택해야 한다면 1번 방식이 더 간편하고 NSubstitute 2번 에는 획기적인 변경 사항이 없으므로 마이그레이션하는 데 문제가 되지 않기 때문에 저는 1번 방식을 선호합니다.

@AutoFixture/core 어떻게 생각하세요? ;-)