Autofixture: مناقشة نهج التبعية البديل

حاليًا يعتمد مشروع AutoNSubstitute على NSubstitute 1.5 . ومع ذلك ، يعاني التكامل الحالي من مشكلات وقيود كبيرة (انظر # 720 و # 592 و # 707 و # 653). هناك طريقة لإصلاحها ، لكننا نحتاج إلى واجهة برمجة التطبيقات التي ظهرت في NSubstitute 2.0.2 فقط. لذلك ، نحتاج إلى تحديد كيفية المضي قدمًا في مكتبة الغراء هذه.

الطريقة 1 - احتفظ بمشروع واحد AutoNSubstitute

بهذه الطريقة نواصل مشروع AutoNSubstitute لكن نزيد تبعية NS البديلة إلى 2.0.2 . سنقدم هذا التغيير في الإصدار 4 فقط وسنصف ذلك في صفحة "كسر التغييرات" ، حتى لا تكون هذه مشكلة.

__النماذج: __

• سيكون لدينا مشروعين أقل لدعم (الغراء + الاختبارات) 😉
• ارتباك أقل. نحتاج إلى إصدار مطلق من lib لإجراء إصلاح الأخطاء وتغيير السلوك (دعم الأدوية). إذا طبقنا ذلك في الإصدار 2 فقط ، فقد يكون الأمر محيرًا تمامًا لأن السلوك مختلف في مكتبات الغراء المختلفة. بقدر ما أعرف ، تقدم جميع إصدارات مكتبة الغراء حاليًا نفس الوظيفة.

الطريقة 2 - إنشاء مشروع AutoNSubstitute2

عادة نتبع هذه الطريقة عندما أردنا دعم إصدار آخر من المكتبة. ومع ذلك ، فإن AFAIK في هذه الحالات كان سبب وجود المشروع هو التغييرات المفاجئة بدلاً من قيود الوظائف (إذا رأيت ذلك بوضوح).

__النماذج: __

• نستمر في دعم جميع المكتبات البديلة
• لا توجد تغييرات فاصلة لبديل NS الأصلي ، لذلك سيكون من الأسهل استهلاك الإصدار 4 (سيكون من الممكن ترحيل الحل خطوة بخطوة). سيكون لدى المستخدمين القدرة على الاختيار عندما يريدون التبديل إلى NSubstitute 2 ومكتبة الغراء الجديدة.

__سلبيات:__

• لا تزال مكتبة AutoNSubstitute متوافقة مع NSubstitute 2.0.0 ، لذلك سيكون من الفوضى أن يكون لديك نسختان متوافقتان من مكتبة الغراء. بالطبع ، يمكننا وضع حد أقصى لـ AutoNSubstitute v1 ، لكن هذا القيد سيكون كذبة صغيرة لأن كل شيء ثنائي على ما يرام 😞

أنا شخصياً ليس لدي رأي قوي هنا لأنني أرى قيمة في كلا النهجين. ومع ذلك، إذا أنا تضطر إلى الاختيار، كنت تفضل الطريقة 1 لأنه من الأسهل وNSubstitute 2 لم يكن لديك تغييرات كسر، بحيث لن يكون هناك مشكلة في الهجرة إليها.

@ AutoFixture / core ما رأيك؟ ؛-)