Page 24 - 4787
P. 24

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

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

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

               стратегія  тестування  приводить  до  значної  кількості  не  пройдених  тестів,

               важливо  їх  виправляти  в  індивідуальному  порядку.  Просте  вилучення,

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

               виявити при покритті тестами.

                        Видимість  коду.  Тести  повинні  мати  доступ  до  тестованого  коду.  З

               іншого боку, принципи інкапсуляції і ховання даних не повинні порушуватися.

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

                       З коду тесту може не бути доступу до private полів і методів. Тому при

               модульному тестуванні може виникнути потреба  в додатковій роботі. В Java

               розробник  може  використати  відображення  (reflection),  щоб  звертатися  до

               полів, які помічені як private. Модульні тести можна реалізувати у внутрішніх

               класах,  щоб  вони  мали  доступ  до  до  членів  зовнішнього  классу.  У  NET

               Framework  можуть  застосовуватися  класи,  що  розділяються  (partial  classes)

               для доступу з тесту до private полів і методів.

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

               залишалися  в  випускному  коді.  У  Сі  для  цього  можуть  бути  використані

               директиви умовної компіляції. Але це буде означати, що випусковий код буде

               повністю  співпадати  з  протестованим.    Систематичний  запуск  інтегрованих

               тестів  на  випуковій  зборці  допомагає  переконатися,  що  не  залишилося  коду,

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

                     Не існує єдиної думки серед програмістів, які застосовують розробку через

               тестування про те, наскільки це осмислено тестувати private- і  protected-методи

               та  дані.  Один  переконаний,  що  досить  протестувати  будь-який  клас  тільки

               через його public-інтерфейс, оскільки private-члени – це лише деталі реалізації,

               яка  може  змінюватися,  і  її  зміни  не  повинні  відображатися  на  наборі  тестів.

               Інші  стверджують,  що  важливі  аспекти  функціональності  можуть  бути

               реалізовані  в   private-  методах  і  тестування  їх  неявно  через  public-інтерфейс




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