Додайте одиничний тест для кожної нової помилки

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

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

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

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

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

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

Абсолютно!

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

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

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

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

Є цитата, яку я не можу повністю пригадати чи знайти, але приблизно це: "Кожна помилка - це ще не написаний тест".

Спроба продати його як тест регресії - це програна битва, ІМХО. З огляду на те, як рідко ці речі ловить повторну помилку, більшість розробників просто скажуть: "Навіщо турбуватися, коли я можу просто виправити це?"

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

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