Чи слід написати тест, щоб довести, що видалення коду виправляє помилку?

Іноді я натрапляю на ситуацію, коли для виправлення помилки потрібно видалити розділ коду. Пурист TDD (я припускаю) виступає за те, щоб написати невдалий тест, видалити код, а потім спостерігати за проходженням тесту.

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

unit-testing tdd bug

— jhewlett
джерело

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

— Ісмаїл Бадаві,

Тест не стверджує, що код видалено - тест стверджує, що помилка виправлена ...

— user253751

Ви дивитесь на це неправильно. Тест не стверджує, що код було видалено. Тест робить стверджує , певну функціональність.

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

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

— Френк
джерело

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

— Док Браун

Очевидно, що вилучена функціональність неправильно обробляла деякі введення / виведення. Очевидно, що хтось у подальшому може неправильно зрозуміти проблему таким же чином. Якщо ви боїтесь тестування набору, я не думаю, що TDD для вас. Що таке тест-костюм все одно?

— Дору

@DocBrown: Якщо вони роблять TDD, то повинен бути якийсь тест, який вимагає цієї абсурдної функціональності, інакше їм навіть не дозволили б написати цей код в першу чергу! Пам'ятайте, що вам потрібно лише написати абсолютну мінімальну кількість коду для проходження тесту. Якщо немає такої тест, то код ніколи не повинен був написаний в першу чергу , і це може бути просто знищений. Якщо є тест, який примушує цю абсурдну поведінку, то цей тест слід видалити, і тепер ми знаходимося в тому самому випадку, який я описав раніше: тест пропав, видаліть код.

— Йорг W Міттаг

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

— Йорг W Міттаг