Послідовні випробування та одиничні випробування, чи слід вилучати тести?

Як правило, в нашій компанії ми переконуємося, що ми пишемо тест для наших веб-сайтів / веб-додатків. Це означає, що ми отримуємо доступ до URL-адреси, заповнюємо форму, подаємо форму до іншої URL-адреси та перевіряємо результати сторінки. Ми робимо це для перевірки перевірки форми, перевірки наявності шаблонів HTML правильних змінних контексту тощо.

Ми також використовуємо його для опосередкованої перевірки основної логіки.

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

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

Необхідні також кінцеві тести. Як ще ти можеш знати, що ти правильно з'єднав усі підрозділи? У дуже простому коді можна протестувати всі шляхи через код лише тестовими, але якщо ви отримуєте більше шарів, це стає надзвичайно дорогим.

Наприклад, скажімо, що у вас є три шари, кожен з яких має п'ять можливих шляхів. Для тестування всіх контурів у всій програмі знадобиться 5 ³ тестування в кінці, але ви можете протестувати всі шляхи через кожну одиницю лише з 5 · 3 одиничними тестами. Якщо ви робите лише тестування в кінці, багато шляхів закінчуються занедбаними, в основному в обробці помилок і в граничних умовах.

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

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

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

Якщо ви використовуєте таку структуру, як Django або Rails (або власні спеціальні класи), у вас повинен бути клас форми, який буде обробляти валідацію форми. Ви також матимете класи перегляду, які відображають відображені шаблони та форму та обробляють запити GET та POST.

В кінцевому підсумку ви:

1. отримати URL-адресу
2. заповнити форму дійсними даними
3. опублікувати форму в URL
4. переконайтесь, що базу даних оновлено чи виконано якусь дію внаслідок дійсної форми

Ви випробовуєте багато коду, і покриття буде досить гарним, але ви протестуєте щасливий шлях лише тоді, коли все піде правильно. Як ви гарантуєте, що форма має в ній правильну перевірку? Що робити, якщо ця форма використовується на кількох сторінках? Ви пишете ще один тест для закінчення?

Спробуємо це ще раз з одиничними тестами:

1. перевірити метод GET перегляду
2. перевірити метод POST перегляду на формі підробленої / макетної
3. перевірити форму з дійсними даними
4. перевірити форму з недійсними даними
5. перевірити побічні ефекти форми

Використовуючи одиничні тести, ви випробовуєте менші фрагменти коду, а тести є специфічними та простішими для запису. Поєднавши це з TDD (Test Driven Development), ви отримаєте код вищої якості.

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

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

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

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

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

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