Page 25 - 4787
P. 25

лише  ускладнить  ситуацію:  модульне    тестування  передбачає  тестування

               найменших можливих модулів функціональності.

                       Fake-, mock –  об’єкти та інтеграційні  тести. Модульні тести тестують

               кожний модуль окремо. Не важливо, чи містить модуль сотні тестів, чи всього

               п’ять. Тести, що використовуються при розробці через тестування, не повинні

               перетинати  межі  процесу,  використовувати  мережеві  з’єднання.  В  іншому

               випадку  проходження  тестів  буде  займати  значний  час.  І  розробники  будуть

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

               модулів  або  даних  також  перетворюють  модульні  тести  в  інтеграційні.  При

               цьому якщо один модуль у ланцюжку веде себе невірно, може бути не відразу

               зрозуміло як саме.

                        Коли  код,  що  розробляється  використовує  база  даних,  веб-  сервери  або

               інші зовнішні процеси, є сенс виділити частину, що покривається тестами. Це

               виконується в два кроки:

                      1.     Всюди, де необхідний доступ до зовнішніх ресурсів, повинен бути

               оголошений інтерфейс, через який цей доступ буде здійснюватися.

                      2.     Інтерфейс повинен мати дві реалізації. Перша, власне надає доступ

               до ресурсу, і друга, що є fake- або mock-об’єктом. Все, що робить fake- об’єкти,

               це додають повідомлення вигляду «Об’єкт person збережено» в лот, щоб потім

               перевірити правильність поведінки.  Mock-об’єкти відрізняються від  fake- Тим,

               що самі містять твердження  ( assertion), що перевіряють поведінку коду, який

               тестується.  Методи  fake-  і  mock-об’єктів,  що  повертають  дані,  можна

               налагодити так, щоб вони повертали при тестуванні одні і ті ж правдоподібні

               дані. Вони можуть емалювати помилки так, щоб код обробки помилок, міг бути

               детально  протестований.  Іншими  прикладами    fake-служб,  що  корисні  при

               тестуванні,  можуть  бути:  служба  кодування,  яка  не  кодує  дані,  генератор

               випадкових чисел, який завжди видасть одиницю. Fake- або mock- реалізації є

               прикладами впровадження залежності (dependency injection).

                         Використання fake- і mock-об’єктів для представлення зовнішнього світу

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

               протестовані  в  результаті  процесу  розробки  через  тестування.  Щоб  уникнути

                                                                                                             24
   20   21   22   23   24   25   26   27   28   29   30