Чи слід завжди виправляти тестові помилки під час їх виправлення?

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

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

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

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

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

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

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

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

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

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

Так, слід.

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

Однак це не практика TDD. У тестах TDD керує вашим дизайном, але у вашому випадку про дизайн вже вирішено.