Як провести тести?

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

Я можу придумати три можливі типи помилок у тестах:

1. Логічні помилки, коли програміст неправильно зрозумів завдання під рукою, а тести роблять те, що він вважав, що вони повинні зробити, що неправильно;

2. Помилки в базовій основі тестування (наприклад, протікає глузуюча абстракція);

3. Помилки в тестах: тест робиться дещо інакше, ніж те, що вважає програміст.

Помилки типу (1), здається, неможливо запобігти (якщо програміст просто ... стає розумнішим). Однак (2) та (3) можуть бути простежувані. Як ви ставитеся до подібних помилок? Чи є у вас якісь спеціальні стратегії, щоб їх уникнути? Наприклад, ви пишете якісь спеціальні "порожні" тести, які перевіряють лише припущення автора тесту? Крім того, як ви підходите до налагодження зламаного тестового випадку?

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

1. Існує кілька методик, які не дозволяють вам додавати однакову помилку як у вашому коді, так і в тестах:

   1. Клієнт повинен бути іншою людиною, ніж виконавець.
   2. Спочатку напишіть тести, а потім код (наприклад, у Test Driven Development).

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

3. Ви можете мати помилки в тестах, але зазвичай вони легко потрапляють, оскільки тести перевіряються розробленим кодом. Між кодом і тестами у вас є зворотній зв'язок із самозабезпеченням. Обидва прогнозують, як повинен поводитися конкретний виклик інтерфейсу. Якщо відповідь інша, вам не потрібна помилка в коді. Ви можете також помилитися в тесті.

Спробуйте зробити індивідуальні тести якомога меншими (короткими).

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

Зрештою, це, мабуть, лише питання досвіду. Чим більше тестів ви напишете, тим краще станете на ньому, тим менше шансів у вас зробити хитрі тести.

Одна з тактик - написати тест перед кодом, який він тестує, і переконатися, що тест спочатку не виходить з правильної причини. Якщо ви використовуєте TDD, ви повинні пройти принаймні цей рівень тестування тестів.

Більш вичерпним способом перевірити якість тестового набору є використання тестування на мутації .

Для №1 і №3: Тести одиниць не повинні містити ніякої логіки, якщо ви це зробите, то ви, мабуть, випробовуєте більше ніж одне в своєму одиничному тесті. Один найкращий досвід для одиничного тестування - це лише один тест на одиницю випробування.

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

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

Повинно бути момент, коли слід зупинити спроби одиничного тестування. Слід знати, коли провести лінію. Чи слід писати тестові випадки для перевірки тестових випадків? А як щодо нових тестових випадків, написаних для тестових тестів? Як ми їх перевіримо?

if (0 > printf("Hello, world\n")) {
  printf("Printing \"Hello, world\" failed\n");
}

Редагувати: Оновлено з поясненнями, як запропоновано коментарем.

Гей.
Ви маєте додатки:

• Ваш продукт
• Ваш тест на цей продукт.

Коли ви проводите тести на свій продукт, вас насправді цікавить не сам тест, а взаємодія між вашим продуктом та вашими тестами. Якщо тест не вдається, це не говорить про те, що програма має помилку. У ньому йдеться про те, що взаємодія між продуктом та тестом не була успішною . Тепер ваша робота визначити, що пішло не так. Це може бути будь-який:

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

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

Тести перевіряють лише деякі частини програми. Я тестую додаток, тестую тести.

Тести не повинні бути достатньо «розумними», щоб ховати помилок.

Код, який ви пишете, реалізує набір специфікацій. (Якщо X, то Y, за винятком випадків Z, у цьому випадку Q, тощо). Всі тести, які слід намагатися виконати, це визначити, що X насправді є Y, якщо тільки Z в цьому випадку Q. Це означає, що все тест повинен робити, це встановити X і перевірити Y.

Але це стосується не всіх випадків, ви, напевно, говорите, і ви матимете рацію. Але якщо ви зробите тест "розумним" достатньо, щоб знати, що X повинен бути лише Y, якщо не Z, то ви в основному повторно реалізуєте бізнес-логіку в тесті. Це проблематично з причин, які ми розберемо трохи глибше нижче. Ви не повинні покращувати покриття коду, зробивши перший тест "розумнішим", замість цього слід додати другий тупий тест, який встановлює X і Z і підтверджує Q. Таким чином, у вас буде два тести, один, який охоплює загальний випадок ( іноді також відомий як щасливий шлях) і той, який охоплює край край як окремий тест.

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

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

TL: DR: Якщо ваші тести потребують тестування, ви робите це неправильно. Пишіть тупі тести .

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

Коротка відповідь: Виробничий код тестує тести .

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

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

Зауважте, що помилки вашого типу (1) неможливо знайти за допомогою тестування одиниць. Щоб уникнути подібних помилок потрібні інші інструменти.