تزامن وهمية مع تطبيقات حقيقية

تنبثق مشكلة المزامنة عند مناقشة استراتيجيات الاختبار. بشكل أساسي - بسبب الحمل الإضافي الذي تنشئه mokas للمطورين وأيضًا مخاطر الابتعاد عن التبعيات الحقيقية.

لذا ، ما هي الطريقة الأقل تكلفة لضمان تزامن الموكاس مع تطبيقات حقيقية؟

للمزامنة ، يمكننا كتابة اختبار يقوم بنفس الاختبارات ضد mok والتنفيذ الحقيقي.

يبدو مثل هذا (أكتب بدون DI ، لكن مع DI أصبح أبسط وأكثر صحة):

public abstract class AbstractValidOrderDaoTest(){ Dao dao; public abstract arrange(); @Test public void whenValidOrderInDb_thenReturnValidOrder(){ arrange(); Order order = dao.retrieve(); assertNotNull(order); assertNotNull(order.getCustomerName()); //    } } public class ValidOrderDaoTest extends AbstractOrderDaoTest(){ @Override public void arrange(){ dao = new FakeValidOrderDao(); } } public class OrderDaoTest extends AbstractOrderDaoTest(){ @Override public void arrange(){ dao = new RealOrderDao(new ValidOrderDataSource(url, user, pwd)); } } 

OrderDaoTest يعمل ضد كائن حقيقي مع وهمية وهمية أو التبعية الحقيقية ، و ValidOrderDaoTest يعمل ضد وهمية.

إذا كانت ValidOrderDataSource هي قاعدة بيانات حقيقية ، فسيكون OrderDaoTest في حزمة منفصلة وسيتم تشغيله كجزء من اختبارات التكامل ، والتي قد تتعطل من وقت لآخر عند تحديث قاعدة البيانات ، على سبيل المثال. هذا لا ينبغي أن تتداخل مع CI \ CD.

إذا كانت ValidOrderDataSource هي قاعدة بيانات وهمية ، فسيتم تشغيل OrderDaoTest مع بقية اختبارات الوحدة.

منذ التزامن الصوري ينطوي على اختبار فئة حقيقية ، ثم ل
سوف تضطر الطبقة الحقيقية إلى تبعية تبعياتها الأساسية. علاوة على ذلك ، يجب أن يتصرف إدمان موك الأساسي وفقًا للسيناريو الخاص بـ Mok. في حالتنا ، هذا
ValidOrderDataSource.

إذا فكرت في الأمر ، فمن المنطقي - أي بيان حول سلوك الطبقات العليا يعني ضمنيًا بعض السيناريوهات في الفئات الأساسية. إذا أرجعت وحدة التحكم شيئًا ما من الخدمة ، فسيكون من الجيد أن توفره القاعدة.

بالمقابل ، غالبًا ما تعيش الطبقات العليا بأفكار غير واقعية عن الطبقات الدنيا ، لذلك ليس من الجيد إزالة البرامج النصية غير الضرورية.

يشير التكرار إلى أنه لكي تتم مزامنة النموذج الأعلى ، فإنك تحتاج إلى بدء مزامنة كافة الأحجار الأساسية حتى التبعيات الخارجية.

هذا يجعل مواصفات النظام أكثر شفافية ، حيث تعتمد سيناريوهات أكثر عمومية وتجريدية على أكثر خاصة.

لاحظ أيضًا أن هناك mokas التي لا تحتاج إلى مزامنتها. أي ليس لدينا مثل هذا التنفيذ الحقيقي الذي يحتاج إلى اختبار شامل. وهذا ينطبق على سيناريوهات الخطأ الرئيسية. EmptyResultException_Datasource على سبيل المثال هذا يقلل كثيرا من عدد الاختبارات التبادلية اللازمة.

بالتأكيد هناك حاجة إلى التزامن من خلال التبعيات الخارجية الحقيقية ، مثل قوائم الانتظار والخدمات الخارجية وقواعد البيانات - خاصة فيما يتعلق بالبيانات التي يأخذونها ويعيدونها.

إذا تغيرت الخدمة الخارجية فجأة ، والتي غالبًا ما تكون في مرحلة التطوير ، فلن نتمكن من التحقق من سلوكها إذا لم نكتب اختبار التزامن.

من حيث كثافة اليد العاملة. في حد ذاته ، لدينا بالفعل اختبار حقيقي مع بعض التبعيات الوهمية التعسفية. بالمقارنة مع الاختبارات غير المتزامنة ، نحتاج إلى القيام ببعض الأشياء.

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