Залежно від того, куди ви дивитесь, ви отримаєте дещо різні відповіді. Я багато читав про цю тему, і ось моя дистиляція; знову ж таки, вони злегка хиткі, і інші можуть не погодитися.
Тестові одиниці
Тестує найменшу одиницю функціональності, як правило, метод / функцію (наприклад, заданий клас із певним станом, виклик методу x у класі повинен спричинити y). Тести одиниць повинні бути зосереджені на одній конкретній особливості (наприклад, виклик методу pop, коли стек порожній, повинен кидати InvalidOperationException). Все, чого вона торкнеться, слід робити на пам’ять; це означає, що тестовий і тестовий код не повинні:
- Зателефонуйте до (нетривіальних) співробітників
- Доступ до мережі
- Натисніть на базу даних
- Використовуйте файлову систему
- Закрутити нитку
- тощо.
Будь-який вид залежності, який повільно / важко зрозуміти / ініціалізувати / маніпулювати, повинен бути заглушений / знущається / керуватися за допомогою відповідних методик, щоб ви могли зосередитись на тому, що робить одиниця коду, а не на тому, що його залежність.
Коротше кажучи, одиничні тести є максимально простими, легкими для налагодження, надійними (за рахунок зменшення зовнішніх факторів), швидкими у виконанні та допомагають довести, що найменші будівельні блоки вашої програми функціонують за призначенням до того, як їх скласти. Застереження полягає в тому, що, хоча ви можете довести, що вони відмінно працюють у відриві, одиниці коду можуть підірватися, коли поєднати, що приведе нас до ...
Інтеграційні тести
Інтеграційні тести ґрунтуються на одиничних тестах, комбінуючи одиниці коду та перевіряючи правильність функціонування отриманої комбінації. Це може бути або внутрішня частина однієї системи, або комбінування декількох систем разом, щоб зробити щось корисне. Крім того, інша річ, яка відрізняє інтеграційні тести від одиничних тестів, - це довкілля. Інтеграційні тести можуть і використовуватимуть потоки, отримуватимуть доступ до бази даних або робити все необхідне, щоб забезпечити правильність роботи всіх кодів та різних змін середовища.
Якщо ви створили якийсь код серіалізації і блок перевірив його внутрішню частину, не торкаючись диска, то як ви знаєте, що він буде працювати при завантаженні та збереженні на диску? Можливо, ви забули промити та розпоряджатися потоками файлів. Можливо, ваші дозволи на використання файлів неправильні, і ви протестували внутрішню частину, яка використовується в потоках пам'яті. Єдиний спосіб достеменно це перевірити - це перевірити його на «справжнє», використовуючи середовище, найближче до виробництва.
Основна перевага полягає в тому, що вони знайдуть помилки, які не можуть перевірити одиничні тести, такі як помилки підключення (наприклад, екземпляр класу A несподівано отримує нульовий екземпляр B) та помилки середовища (він працює добре на моїй машині з одним процесором, але мій чотири основні машини колеги не можуть пройти тести). Основним недоліком є те, що тести інтеграції стосуються більшої кількості коду, менш надійні, діагностування відмов важче, а тести важче підтримувати.
Також інтеграційні тести не обов'язково доводять, що повноцінна функція працює. Користувач може не піклуватися про внутрішні деталі моїх програм, але я це роблю!
Функціональні тести
Функціональні тести перевіряють певну особливість на правильність, порівнюючи результати для заданого введення та специфікації. Функціональні тести не стосуються проміжних результатів або побічних ефектів, лише результату (їх не хвилює, що після виконання x, об'єкт y має стан z). Вони записуються для перевірки частини специфікації, наприклад, "виклик функції Square (x) з аргументом 2 повернення 4".
Тести на прийняття
Здається, тестування на прийняття розбито на два типи:
Стандартне тестування приймання включає проведення тестів у всій системі (наприклад, використання веб-сторінки через веб-браузер), щоб побачити, чи задовольняє функціональність програми специфікація. Наприклад, "натискання значка масштабування повинно збільшити перегляд документа на 25%." Немає справжнього континууму результатів, лише результат пропуску чи невдачі.
Перевагою є те, що тести описані простою англійською мовою і забезпечують, що програмне забезпечення в цілому є функціональним завершенням. Недоліком є те, що ви перемістили інший рівень вгору на тестову піраміду. Тести на прийняття торкаються гір коду, тому відстежувати несправність може бути складним.
Крім того, в умовах гнучкої розробки програмного забезпечення тестування прийнятності користувачів передбачає створення тестів для відображення історій користувача, створених / для замовника програмного забезпечення під час розробки. Якщо тести пройдуть, це означає, що програмне забезпечення повинно відповідати вимогам замовника, і розповіді можна вважати завершеними. Набір тестових програм прийняття - це в основному виконувана специфікація, написана мовою, визначеною для домену, яка описує тести мовою, якою користуються користувачі системи.
Висновок
Всі вони доповнюють один одного. Іноді вигідно зосередитись на одному типі або повністю відмовитися від них. Основна відмінність для мене полягає в тому, що деякі тести розглядають речі з точки зору програміста, тоді як інші використовують фокус на клієнта / кінцевого користувача.