Page 111 - 4190

дів. Вона зосереджується на тестуванні окремо взятих модулів, вико-
ристовуючи mock-об’єкти для представлення зовнішнього світу.
4. Вимагається більше часу для розроблення і підтримки, а заохо-
чення з боку керівництва дуже важливе. Якщо в організації немає

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

5. Модульні тести, що створенні при розробленні через тестуван-
ня, як правило, пишуться тими ж хто пише код для тестування. Якщо
програміст неправильно усвідомив вимоги до додатка, то і тест, і тес-
тує мий модуль будуть містити помилку.

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

7. Тести самі по собі є джерелом накладних витрат. Погано напи-
сані тести, наприклад, містять жорстко вшиті рядки з повідомленням
про помилки або піддані помилкам, дорогі при підтримці. Щоб спро-

стити підтримку тестів необхідно повторно використати повідомлен-
ня про помилки з коду, що тестується.
8. Рівень покриття тестами, що отримують у результаті розроб-

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

рядку. Просте вилучення, відключення або поспішна зміна може при-
вести до пропусків, які важко виявити при покритті тестами.
Видимість коду. Тести повинні мати доступ до тестованого коду.

З другого боку, принципи інкапсуляції і приховування даних не по-
винні порушуватися. Тому модульні тести пишуть в тому ж модулі
або проекті, що і тестований код.
З коду тесту може не бути доступу до private полів і методів. То-

му при модульному тестуванні може виникнути потреба в додатковій
роботі. У Java розробник може використати відображення (reflection),
щоб звертатися до полів, які помічені як private. Модульні тести мо-

жна реалізувати у внутрішніх классах, щоб вони мали доступ до чле-
нів зовнішнього классу. У NET Framework можуть застосовуватися
класи, що поділяються (partial classes) для доступу з тесту до private

полів і методів.
Важливо, щоб фрагменти коду, що призначені виключно для тес-

111