Як слід перевірити свій код TEST?

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

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

Мені здається, що найкращим способом зробити це було б переконатися, що тест не спрацьовує з помилковим кодом. * Якщо я витрачаю 2 хвилини по черзі на додавання помилок до коду і переконуюсь, що він не працює, я повинен мати впевнену ступінь впевненості, що тести "працюють". Це підводить мене до мого другого питання: Які хороші способи ввести помилки, щоб переконатися, що вони потрапили в тестові випадки? Якщо я просто випадковим чином коментую заяви, переконайтеся, що неправильна гілка запису if-elseзапускається, відкидаючи його стан, і змінюю порядок виконання коду з побічними ефектами тощо, поки я не переконаюся, що мої тести зловить більшістьзвичайні помилки? Як професійні розробники підтверджують, що їхні тести насправді роблять те, що вони повинні робити? Вони просто припускають, що тести працюють, чи вони також потребують часу, щоб перевірити їх? Якщо так, як вони проводять тести?

Я не пропоную людям витратити стільки часу на тестування своїх тестів, а потім тестувати тести на свої тести, щоб вони ніколи насправді не писали реальний код, але я зробив досить дурні речі, за які я відчуваю, що можу отримати користь "мета-тестування", і було цікаво про найкращий спосіб зробити це. : D

_{* Я міг би перевірити, чи проходить тест при тестуванні коду без помилок, але використання коду як специфікації для тесту здається зовсім зворотним ...}

Стандартний потік для TDD:

1. Напишіть невдалий тест. (Червоний)
2. Зробіть найменшу зміну коду, яка змушує його пройти (зелений)
3. Рефактор (збереження зеленого кольору)

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

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

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

Один із підходів - тестування мутацій , використовуючи такий інструмент, як Jester :

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

Тести на тести? Не йдіть цією дорогою. Тоді вам, певно, знадобляться тести для тестів для тестів, а потім тести для тестів для тестів для тестів ... де ви зупиняєтесь?

Звичайний потік тестування проходить так, і як розробник, ви витратите більшу частину свого часу на точки 1-3:

1. Код
2. Одиничні тести
3. Інтеграційні тести
4. Система / інші автоматизовані
5. QA / людські тестери

Якщо я витрачаю 2 хвилини по черзі на додавання помилок у код (...)

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

Якщо мені просто випадково коментувати заяви, переконайтеся, що неправильна гілка if-else запускається, заперечуючи її стан (...)

Це насправді життєздатний підхід для перевірки того, чи справді ви перевіряєте те, що вважаєте, що робите. Я не думаю, що це завжди так добре, як це страждає від тієї ж проблеми, що і "тест на тест для тесту ..." річ: коли ви перестанете змінювати код, знаючи код, ви тестуєте 100% працює?

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

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

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

Розглянемо це. Яка мета одиничного тесту? Він повідомляє вас, коли будь-яка з численних змін, які ви внесете у свою основну програму, випадково змінить логіку в цій програмі. Ви хочете мати це, тому що знаєте, що будь-яка зміна може щось зламати. Саме тому немає жодних проблем, якщо ви не перевіряєте тест: ви не возиться зі своїм тестом, поки навмисно не зміните логіку вашої програми (що вимагатиме від вас переглянути тест і ще раз перевірити його), тож ваш тест, швидше за все, не зламається випадково.

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

Ми можемо використовувати це для оцінки самого "тесту".

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

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