Page 23 - 4787

механічно продемонструвати адекватність розробленого коду в області безпеки

даних і взаємодії між процесами. Безумовно, безпека основана на коді, в якому

не повинно бути дефектів. Але вона основана також на участі людини в

процедурах захисту дипломних. Тонкі проблеми, що виникають в області

взаємодії між процесами, неможливо з впевненістю відновити, просто

запустивши деякий код.

3. Розробку через тестування складно застосовувати в тих випадках,

коли для тестування необхідне проходження функціональних тестів.

Прикладами може бути: розробка інтерфейсу користувача, програм, що

працюють з базами даних, а також того, що залежить від специфічної

конфігурації мережі. Розробка через тестування не передбачає великого обсягу

роботи з тестування для таких прикладів. Вона зосереджується на тестуванні

окремо взятих модулів, використовуючи mock-об’єкти для представлення

зовнішнього світу.

4. Вимагається більше часу для розробки і підтримки, а заохочення з

боку керівництва дуже важливе. Якщо в організації немає впевненості в тому,

що розробка через тестування покращить якість продукту, то час, затрачений на

написання тестів, можна розглядати, як затрачений дарма.

5. Модульні тести, що створенні при розробці через тестування, як

правило, пишуть тиі ж, хто пише тестований код. Якщо програміст

непровильно усвідомив вимоги до додатка, то і тест, і тестований модуль

будуть містити помилку.

6. Значна кількість тестів, які використовують можуть утворювати

хибне відчуття надійності, що приводить до меншої кількості дій з контролю

якості.

7. Тести самі по собі є джерелом накладних витрат. Погано написані

тести, наприклад, містять жорстко вшиті рядки з повідомленням про помилки

або піддані помилкам, дорогі при підтримці. Щоб спростити підтримку тестів,

необхідно повторно використати повідомлення про помилки з коду, що

тестується.

22