5. Модифікований низхідний метод

Низхідний підхід має ще один істотний недолік, що стосується повноти тестування. Передбачимо, що є велика програма і десь ближче до нижнього її рівня знаходиться модуль, призначений для обчислення коріння квадратного рівняння. Для заданих вхідних змінних А, В і З він вирішує рівняння .

При проектуванні і програмуванні модуля з такою функцією завжди слід розуміти, що квадратне рівняння може мати як дійсне, так і комплексне коріння. Для повної реали­зации цієї функції необхідно, аби результати могли бути дей­ствительными або комплексними числами (або, якщо дополнитель­ные витрати на знаходження комплексного коріння не виправдані, модуль повинен принаймні повертати код помилки у разі, коли вхідні коефіцієнти задають рівняння з комплексним корінням). Передбачимо, що конкретний контекст, в якому використовується модуль, виключає комплексне коріння (тобто вызы­вающие модулі ніколи не задають вхідних параметрів, які привели б до комплексного коріння). При строго низхідному методі інколи буває неможливо тестувати модуль для випадку комплек­сных коріння (або тестувати помилкові умови). Можна попы­таться виправдовувати це тим, що, оскільки таке рівняння ніколи не буде дано модулю, нікого не повинно турбувати, чи працює він і в цих випадках. Так, це байдуже зараз, але виявиться важливим в майбутньому, коли хтось спробує використовувати модуль в новій програмі або модифікувати стару програму так, що стануть можливими і комплексне коріння.

Ця проблема виявляється у всіляких формах. Застосовуючи низхідне тестування в точній відповідності з попереднім розділом, часто неможливо тестувати певні логічні умови, наприклад помилкові ситуації або захисні перевірки. Низхідний метод, крім того, робить складною або взагалі неможливою перевірку виняткових ситуацій в деякому модулі, якщо програма працює з ним лише в обмеженому кон­тексте (це означає, що модуль ніколи не отримає досить повний набір вхідних значень). Навіть якщо тестування такої си­туации в принципі здійсненно, часто буває важко визначити, які саме потрібні тести, якщо вони вводяться в точці програми, віддаленої від місця перевірки відповідної умови.

Метод, званий модифікованим низхідним підходом, вирішує ці проблеми: потрібний, аби кожен модуль прошел автономне тестування перед підключенням до програми. Хоча це дійсно вирішує всі перераховані проблеми, тут тре­буются і драйвери, і заглушки для кожного модуля.

6. Метод великого стрибка.

Ймовірно, найпоширеніший підхід до інтеграції мо­дулей — метод «великого стрибка». Відповідно до цього методу кожен модуль тестується автономно. Після закінчення тестування модулів вони інтегруються в систему все відразу.

Метод великого стрибка в порівнянні з іншими підходами име­ет багато недоліків і мало достоїнств. Заглушки і драйвери не­обходимы для кожного модуля. Модулі не інтегруються до найостаннішого моменту, а це означає, що протягом довгого часу серйозні помилки в сполученнях можуть залишитися невиявленими. Метод великого стрибка значно ускладнює відладку.

Та все ж великий стрибок не завжди небажаний. Якщо програм­ма мала і добре спроек­тирована, він може виявитися прийнятним. Проте для крупних програм метод великого стрибка зазвичай згубний.