писання спеціального коду-оболонки, що викликає модуль, що тестується. Якщо він, у свою чергу, викликає інший модуль, для нього потрібно написати В«заглушкуВ». Заглушка - це імітація викликається функції, що повертає ті ж дані, але нічого більше не робить. p align="justify"> Зрозуміло, що написання оболонок і заглушок уповільнює роботу, а для кінцевого продукту вони абсолютно не допомагають. Але написані одного разу, ні елементи можуть використовуватися повторно при кожній зміні про-флмми. Хороший набір оболонок і заглушок - це дуже ефективний інструмент тестування. p align="justify"> На противагу висхідному тестуванню, стратегія цілісного тестування передбачає, що до повної інтеграції системи її окремі модулі не проходять особливо ретельного тестування.
Перевагою такої стратегії є те, що немає необхідності в написанні додаткового коду. Тому багато керівників вибирають цей спосіб з міркувань економії часу - вони вважають, що краще розробити один великий набір тестів і з його допомогою за один раз перевірити всю систему. Але таке уявлення абсолютно помилково, і ось чому. p align="justify"> Дуже важко виявити джерело помилки. Це головна проблема. Оскільки жоден з модулів не перевірений як слід, в більшості з них є помилки. Виходить, що питання не стільки в тому, в якому модулі сталася виявлена ​​помилка, скільки в тому, яка з помилок у всіх залучених до процесу модулях призвела до отриманого результату. І коли накладаються помилки декількох модулів, ситуацію може бути набагато важче локалізувати і повторити. p align="justify"> Крім того, помилка в одному з модулів може блокувати тестування іншого. Як протестувати функцію, якщо викликає її модуль не працює? Якщо не написати для цієї функції програму-оболонку, доведеться чекати налагодження модуля, а це може затягнутися надовго. p align="justify"> Важко організувати виправлення помилок. Якщо програму пишуть кілька програмістів (а саме так і буває у великих системах), і при цьому невідомо, в якому модулі помилка, хто ж буде її шукати і виправляти? Один програміст буде вказувати на іншого, той, з'ясувавши, що його код ні при чому, знову звернеться до першого, а в результаті буде сильно страждати швидкість розробки. p align="justify"> Процес тестування погано автоматизований. Те, що на перший погляд здається перевагою цілісного тестування - відсутність необхідності писати оболонки і заглушки, - насправді обертається його недоліком. У процесі розробки програма щодня змінюється, і її доводиться тестувати знову і знову. А оболонки і заглушки допомагають автоматизувати цей одноманітний працю. p align="justify"> Існує і ще один принцип організації тестування, при якому програма так само, як і при висхідному способі, тестується не цілком, а частинами. Тільки напрямок руху змінюється - спочатку тестується самий верхній рівень ієрархії модулів, а від нього тестувальник поступово спускається вниз. Така технологія називається низхідній (top-down). Обидві технол...
