иці питання вибору стратегії тестування зазвичай вирішується просто: кожен модуль по можливості тестується відразу після його написання, в результаті послідовність тестування одних частин програми може виявитися висхідній, а інших - низхідній.
Спадний тестування (зване також низхідній розробкою не є повною протилежністю висхідному, але в першому наближенні може розглядатися як таке, При низхідному підході програма збирається і тестується зверху вниз. Ізольовано тестується тільки головний модуль. Після того як тестування цього модуля завершено, з ним з'єднуються (наприклад, редактором зв'язків) один за іншим модулі, безпосередньо викликані їм, і тестується отримана комбінація. Процес повторюється до тих пір, поки не будуть зібрані і перевірені всі модулі.
При цьому підході негайно виникає два питання: що робити, коли тестований модуль викликає модуль більш низького рівня (якого в даний момент ще не існує), і як подаються тестові дані. Відповідь на перше питання полягає в тому, що для імітації функцій відсутніх модулів програмуються модулі-заглушки », які моделюють функції відсутніх модулів. Фраза «просто напишіть заглушку» часто зустрічається в описі цього підходу, але вона здатна ввести в оману, оскільки завдання написання заглушки »може виявитися важким. Адже заглушка рідко зводиться просто до оператора RETURN, оскільки викликає модуль зазвичай очікує від неї вихідних параметрів. У таких випадках в заглушку вбудовують фіксовані вихідні дані, які вона завжди і повертає. Це іноді виявляється неприйнятним, так як зухвалий модуль може розраховувати, що результат виклику залежить від вхідних даних. Тому в деяких випадках заглушка повинна бути досить витонченої, наближаючись по складності до модуля, який вона намагається моделювати.
Цікавий і друге питання: в якій формі готуються тестові дані і як вони передаються програмі? Якби головний модуль містив всі потрібні операції введення і виведення, відповідь була б проста:
Тести пишуться у вигляді звичайних для користувачів зовнішніх даних і передаються програмі через виділені їй пристрої введення. Так, однак, трапляється рідко. У добре спроектованої програмі фізичні операції введення-виведення виконуються на нижніх рівнях структури, оскільки фізичний введення-виведення - абстракція досить низького рівня. Тому для того, щоб вирішити проблему економічно ефективно, модулі додаються не в строго низхідній послідовності (всі модулі одного горизонтального рівня, потім модулі наступного рівня), а таким чином, щоб забезпечити функціонування операцій фізичного введення-виведення якнайшвидше. Коли ця мета досягнута, спадне тестування отримує значну перевагу: всі подальші тести готуються в тій же формі, яка розрахована на користувача.
Залишається ще одне питання: в якій формі пишуться тести до тих пір, поки не буде досягнута ця мета? Відповідь: вони включаються в деякі з заглушок.
Спадний метод має як переваги, так і недоліки в порівнянні з висхідним. Найзначніше достоїнство - в тому, що цей метод поєднує тестування модуля, тестування сполученні і частково тестування зовнішніх функцій. З цим же пов'язана інша його достоїнство - коли модулі вводу-виводу вже підключені, тести можна готувати в зручному вигляді. Спадний підхід вигідний також у тому випадку, коли є сумніви щодо здійсненності програми в цілому або якщо в проекті програми можуть виявитися серйозні дефекти.
Перевагою спадного підходу дуже часто вважають відсутність необхідності в драйверах; замість драйверів вам просто слід написати «заглушки». Як читач зараз вже, ймовірно, розуміє, це перевага спірно.
Спадний метод тестування має, на жаль, деякі недоліки. Основним з них є той, що модуль рідко тестується досконально відразу після його підключення. Справа в тому, що грунтовне тестування деяких модулів може зажадати вкрай витончених заглушок. Програміст часто вирішує не витрачати масу часу на їхнє програмування, а замість цього пише прості заглушки і перевіряє лише частина умов в модулі. Він, звичайно, збирається повернутися і закінчити тестування розглянутого модуля пізніше, коли прибере заглушки. Такий план тестування безумовно не найкраще рішення, оскільки про відкладених умовах часто забувають.
Другий тонкий недолік низхідного підходу полягає в тому, що він може породити віру в можливість почати програмування і тестування верхнього рівня програми до того, як вся програма буде повністю спроектована. Ця ідея на перший погляд здається економічною, але зазвичай справа йде зовсім навпаки. Більшість досвідчених проектувальників визнає, що проектування програми - процес інтерактивний. Рідко перший проект виявляється досконалим. Нормальний стиль проектування структури програми передбачає по закінченні проектування нижніх рівнів повернутися назад і підправити верхній р...
