Яке значення перевірки при невдалі тестові одиниці?

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

Я буду використовувати простий приклад: Чутливість до справ. Поточний код залежить від регістру. Дійсний вхід до методу - "Cat", і він би повернув перерахунок Animal.Cat. Однак бажана функціональність методу не повинна враховувати регістри. Тож якби описаний метод був переданий "кіт", він, можливо, може повернути щось на зразок Animal.Null замість Animal.Cat, і тестовий пристрій не вдасться. Хоча проста зміна коду зробила б цю роботу, складнішою проблемою може знадобитися тиждень, але ідентифікація помилки з одиничним тестом може бути менш складним завданням.

Програма, яка зараз аналізується, має 4 роки коду, який "працює". Однак останні дискусії щодо одиничних тестів виявили недоліки в коді. Деякі просто потребують явної документації щодо впровадження (наприклад, залежно від регістру чи ні) або коду, який не виконує помилку, залежно від того, як вона зараз викликається. Але одиничні тести можуть бути створені, виконуючи конкретні сценарії, які спричинять побачення помилки та є коректними вхідними даними.

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

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

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

Мені не подобається перевірених ламаних тестів, оскільки вони видають непотрібний шум. Після кожного тестування мені доведеться перевірити всі помилки (червоний). Це червоний колір, тому що з’явилася нова проблема, або тому, що є старе, що відкрито робити / виправити. Це не нормально, якщо є більше 20 одиниць тестів.

Натомість я використовую

• [Ignore("Reason")]атрибут, який робить результат жовтим або
• throw new NotImplementedException()що робить результат сірим

Примітка. Я використовую NUnit для .net. Я не впевнений, чи є "сіра" функція в інших тестових рамках.

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

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

Все, крім "червоного", можна зареєструвати.

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

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

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

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

Коротше кажучи, невдалі одиничні тести дають команді список "TODO".

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

[* За умови, що одиничні тести насправді перевіряють щось корисне.]

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

Ось абзац з початку глави 13 „ Ефективна робота зі спадковим кодексом” :

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

Але зламані, які ідентифікують помилки в новому проекті, названому таким. Таким чином, ви можете побачити, що вони ПОТРІБНІ ... По мірі їх фіксації вони стануть зеленими та переходять у звичайний набір тестів.

ПРИМІТКА. Цей проект повинен був бути встановлений таким чином, щоб він не будувався на сервері збірки, якщо ваш сервер збирання не дозволяє перевіряти, що порушують збірку (якщо ви визначите, що зламана збірка є такою, в якій всі тести не проходять)

Одиничні тести повинні перевіряти випадки помилок на додаток до випадків успіху функції. Функція повинна явно відхиляти неправильний вхід або повинна мати документацію для пояснення того, який вхід вважається дійсним.

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

Суть одиничного тестування не має 100% успіху, справа в пошуку та виправлення помилок у коді. Не робити тести - це простий спосіб досягти 100% успіху, але це не дуже вигідно проекту.

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

Як я бачу TDD, виконаний із впровадженням тестів для незакінченого коду, спочатку записуйте тести з атрибутом [ExpectedException] або подібним. Це повинно пройти спочатку, оскільки неповний код не матиме в ньому логіки і написати в нього новий код Exception (). Незважаючи на те, що виняток через неправильне, це може принести тести спочатку проходження та придатність для перевірки. Ми можемо забути ігнорований тест, але, безумовно, може привести в порядок або заповнити неповний код. Коли ми це зробимо, автоматично відповідний тест, який очікував витримки, зараз почне виходити з ладу і тривожить вас виправити це. Це може включати незначну зміну тесту, щоб позбутися ExpectException, а натомість робити реальні твердження. CI, Dev, тестери та клієнти всі щасливі та безпрограшна ситуація?