ويعتقد أن هناك حاجة إلى اختبارات وحدة. أن نصف الحقيقة مخبأة فيها. وسيتم الكشف عن تلك المعلومات الحقيقية حول سلوك البرنامج فقط عندما نجمعها في اختبار التكامل.
هناك سبب لذلك ، ولكن هل اختبارات الوحدة غير مكتملة حقًا وهل يمكن جعلها أكثر موثوقية؟ كم عدد أسباب عدم اكتمالها؟
لنفترض أن لدينا مكونين مغطيين بالوحدة ، هما Caller و Callee. يتصل المتصل Callee باستخدام وسيطة ويستخدم بطريقة ما الكائن المرتجع. كل مكون من مكوناته له مجموعة من التبعيات ، والتي نقعها.
ما عدد السيناريوهات التي تتصرف فيها هذه المكونات بشكل غير متوقع أثناء التكامل؟
السيناريو الأول هو
مشكلة خارجية لكلا المكونين . على سبيل المثال ، يعتمد كلاهما على حالة قاعدة البيانات ، والترخيص ، ومتغيرات البيئة ، والمتغيرات العامة ، وملفات تعريف الارتباط ، والملفات ، إلخ. الحكم على هذا أمر بسيط للغاية ، لأنه حتى في البرامج الكبيرة جدًا يوجد عادة عدد محدود من نقاط الخلاف هذه.
يمكن حل المشكلة بوضوح ، إما من خلال إعادة تصميم مع تقليل التبعيات ،
أو نقوم بمحاكاة خطأ محتمل مباشرة في سيناريو المستوى الأعلى ، أي أننا نقدم المكون CallingStrategy (OffendingCaller ، OffendedCallee) {} ، ونحاكي تعطل Callee ومعالجة الأخطاء في CallingStrategy. لهذا ، اختبارات التكامل غير مطلوبة ، ولكن يلزم فهم أن السلوك المحدد لأحد المكونات يشكل خطراً على المكون الآخر ، وسيكون من الجيد عزل هذا السيناريو إلى مكون.
السيناريو الثاني: المشكلة في واجهة الكائنات القابلة للتكامل ، أي
تسربت حالة غير ضرورية لأحد الكائنات إلى أخرى .
في الواقع ، هذا خطأ في الواجهة التي تسمح بذلك. حل المشكلة واضح أيضًا - كتابة وتضييق الواجهات ، والتحقق المبكر من المعلمات.
كما نرى ، السببان شائعان للغاية ، لكن سيكون من الجيد التوضيح بوضوح أنه لا يوجد أي سبب آخر.
وبالتالي ، إذا فحصنا فصولنا عن 1) الحالة الداخلية و 2) التبعيات الخارجية ، فلن يكون لدينا سبب للشك في موثوقية اختبارات الوحدة.
(في مكان ما في الزاوية ، يصرخ مبرمج وظيفي بهدوء بعبارة "لقد قلت لك ذلك" ، ولكن ليس حول هذا الأمر الآن).
ولكن يمكننا أن ننسى أو نفتقد نوعًا ما من الإدمان!
يمكن تقدير بوقاحة. افترض أن هناك عشرة سيناريوهات في كل مكون. نحن تخطي سيناريو واحد من أصل عشرة. على سبيل المثال ، Callee بإرجاع فارغة فجأة ، ويتصل المتصل فجأة NullPointerException. نحتاج إلى ارتكاب خطأ مرتين ، مما يعني أن احتمال السقوط في مكان ما هو 1/100. من الصعب أن نتخيل أن سيناريو التكامل للعنصرين سيصطدم بهذا. بالنسبة للعديد من المكونات المسماة بالتتابع داخل اختبار التكامل ، يزداد احتمال اصطياد بعض الأخطاء ، مما يعني أنه كلما طالت مدة اختبار اختبار التكامل ، والمزيد من السيناريوهات ، كلما كان مبرراً أكثر.
(إن الرياضيات الحقيقية لتراكم الأخطاء هي ، بالطبع ، أكثر تعقيدًا ، لكن النتيجة لا تختلف كثيرًا).
ومع ذلك ، في عملية إجراء اختبار التكامل ، يمكننا أن نتوقع زيادة كبيرة في الضوضاء الناتجة عن التبعيات المقطوعة والوقت الكبير الذي تقضيه في العثور على الخطأ ، كما أنها تتناسب مع طول الحزمة.
وهذا يعني أن
اختبارات التكامل ضرورية إذا كانت اختبارات الوحدات سيئة أو مفقودة . على سبيل المثال ، عند فحص برنامج نصي صالح فقط في كل اختبار وحدة ، عندما يستخدمون واجهات واسعة جدًا ولا يقومون بتحليل التبعيات العامة.