Лабораторна робота № 3

Засоби автоматизованого тестування в

інтегрованому середовищі Microsoft Visual Studio

Мета роботи

Ознайомитись з базовим набором інструментів автоматизації тестування в інтегрованому середовищі

розробки Microsoft Visual Studio. Навчитись створювати прості модульні тести та організовувати їх в окремі

бібліотеки.

Короткі теоретичні відомості

У цій роботі вивчається інструментарій автоматизації тестування на прикладі інструментів для

модульного тестування MS Visual Studio. На практиці розглядаються базові поняття про модульне

тестування та розробку через тестування (Test-Driven Development, TDD).

Основні визначення

Модульний тест (Unit test) є набором тестових функцій (зазвичай – методів тестового класу) для

тестування якогось програмного модуля, у тому числі – для тестування класу. Модульне тестування

переслідує наступні основні цілі:

- пошук і усунення помилок;

- верифікація проекту;

- покращення коду модуля (як інструмент рефакторингу);

- документування модуля;

- розробка модуля (у контексті розробки через тестування, TDD) і т. д .

Розробка через тестування (Test-Driven Development) – вживана в екстремальному програмуванні

(Extreme Programming, XP) практика розробки програмних модулів, при якій спочатку створюються

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

що чергуються:

1) Створення/модифікація тесту.

2) Створення/модифікація модуля.

3) Покращення коду модуля (рефакторинг).

Далі знову перший крок – створення/модифікація тесту і так далі. Для цього циклу використовується

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

невдачею, оскільки відсутній необхідний код в модулі ("жовте світло"), що розробляється, потім додається

необхідний для успішної компіляції код, програма компілюється, але тести не проходять ("червоне світло"),

потім в модуль додається необхідний код, тести проходять успішно ("зелене світло"). Після цього

виконується покращення коду (рефакторинг), що супроводжується постійним прогоном тестів. Таким чином

виконується цикл "червоний-зелений-рефакторинг".

В процесі модульного тестування використовуються шаблони (патерни, pattern) тестування, які можна

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

так і до конкретних кроків циклу розробки ("Шаблони червоного світла", "Шаблони зеленого світла" і ін.).

До загальних шаблонів відносяться шаблони "Тестові дані", "Зрозумілі дані", до шаблонів зеленого світла

(чи "Зеленої смуги") відносять шаблони, використовувані для швидкого отримання зеленого світла,

наприклад шаблон "Підробка", шаблон "Тріангуляція", шаблон "Очевидна реалізація", до шаблонів

червоного світла (чи "Червоної смуги") відносять шаблони, використовувані для знаходження рішення при

тривалому неспрацьовуванні тестів, наприклад шаблон "Ще один тест", шаблон "Вивчаючий тест", шаблон

"Тест одного кроку" і т. д .

Серед найпростіших шаблонів можна відмітити наступні:

Тестові дані (Test Data). Загальний шаблон тестування. Це власне просто рекомендація відносно

ретельного вибору даних для тестових перевірок. Дані, що використовуються, повинні робити тест простим

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

підтримувати кілька різновидів вводу, значить усі ці різновиди повинні бути відображені в тесті.

Зрозумілі дані (Evident Data). Загальний шаблон тестування. Рекомендує використовувати в якості

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

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

Підробка (Fake It). Шаблон зеленої смуги. Припускає, що в якості значень, які повертаються функціями

використовуються саме ті константи, які очікуються тестами на виході функцій. Тобто в функціях, що

тестуються, прописується непрацюючий код, який підмінює вихідні дані на ті, які очікує тест. Цей, на

перший погляд, наївний прийом виявляється дуже корисним для того, щоб бути упевненим, що

викликається саме та функція, яку ми чекаємо (це може бути не так, якщо використовується спадкоємство),

та і в інших випадках.

Тріангуляція (Triangulation). Шаблон зеленої смуги. Припускає завдання двох тестових перевірок,

задовольнити яким можна тільки використовуючи деякий алгоритм (формулу) в коді модуля ("третій кут"

трикутника), я не повертаючи константу, як у шаблоні "Підробка".

Очевидна реалізація (Obvious Implementation). Шаблон зеленої смуги. Рекомендація говорить про те,

що коли реалізація деякої простої функції очевидна (або здається такою), її треба написати. Очевидна

реалізація – шаблон швидшої розробки, ніж пара "Підробка"-"Тріангуляція", однак требі бути готовим

вчасно "скинути" швидкість в разі невдачі при написанні швидкої реалізації і перейти на коротші кроки

"Підробка"-"Тріангуляція".

Інструменти модульного тестування

На практиці для модульного тестування часто використовують стандартну оболонку тестування xUnit,

яка реалізована для більшості існуючих мов програмування, наприклад оболонка cppUnit для мови C++ або

nUnit для .NET. В даній роботі розглядається аналогічна до xUnit інфраструктура модульного тестування

Visual Studio.

Інфраструктура модульного тестування в Visual Studio дозволяє створювати тести при створенні

застосувань. Або (якщо використовується керована тестами розробка) можна написати тести до того, як

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

створення повного набору тестів одночасно з розробкою застосування.

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

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

виконані в останню хвилину виправлення, рефакторингу і пізні додавання. Коли відбуваються такі події, то

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

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

Приклад модульного тесту

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

модульний тест — це просто тестовий код, який ви пишете для виклику коду вашого застосування. Цей

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

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

"істина", а він виявляється "брехня", то тест не пройшов. Отже, розглянемо приклад. Припустимо, що у вас є

клас, який реалізує декілька математичних функцій. Наприклад, серед цих функцій є функція, яка обчислює

і повертає квадрат числа. В якості параметру ця функція приймає ціле число. Напишемо тест, який може

підтвердити, що ваш код не лише працює, але і працює правильно:

[TestMethod()]

public void SqrTest()

{

CustomMath custMath = new CustomMath();

int x = 12;

int sqr_x = custMath.Square(x);

Assert.AreEqual(sqr_x, 144);

//створення об’єкту

//тестові дані

//виклик методу для тестування

//перевірка: sqr_x == 144?

}

Зверніть увагу, що цей код схожий на звичайний код на мові C#. Ви позначаєте метод як тест за

допомогою додавання атрибуту TestMethod. Усередині коду ви створюєте об'єкт і робите виклик методу.

Якщо цей виклик закінчується невдало (чи виникає виключення), то тест не проходить. Потім в тісті ви

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

Якщо ця перевірка не проходить (значення не рівні), то тест не проходить. Якщо перевірка проходить, то

тест теж проходить.

Розробка модульних тестів в ms Visual Studio

Існує декілька способів створення модульних тестів в MS Visual Studio. Ви можете зробити це вручну

шляхом створення файлу класу і додавання відповідних посилань, атрибутів і т. п.

Ви можете також додати модульний тест в тестовий проект за допомогою меню Test або контекстного

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