тестова розробка - Хто повинен писати тести?

Спочатку розробник зобов'язаний написати тест, але я помітив, що у багатьох випадках / e-зрілі розробники ці випадки не дають навіть 80% охоплення.
Як щодо мене людина, що займається питаннями якості, призначена написати ВСІ тести для даного проекту замість розробника?
Чи є в цьому якісь мінуси?

У тестовій розробці тести повинні бути написані розробником. Інакше розробкою керує хтось інший, ніж розробник.

Отже, як тільки ви віддасте завдання писати тести не розробнику, ця людина стає розробником.

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

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

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

І останнє, але не менш важливе, у «чистому» ТТД взагалі не повинно бути непокритого коду (оскільки ви спочатку пишете тести). Однак є випадки (хоча люди і сперечаються з цього приводу), коли припустима менша охоплення коду. Деякі, наприклад, стверджують, що написання тестів для одержувачів / сеттерів POJO - це марна трата часу.

ці випадки не дають навіть 80% охоплення

Це може бути проблемою управління.

Або це може бути неактуально.

По-перше, різниця між 80% і 100% покриттям - це, мабуть, великі витрати за дуже малу користь.

"Покриття" може означати що завгодно. Рядки коду, логічні шляхи тощо. Я здогадуюсь, ви маєте на увазі рядки коду (а не логічні шляхи).

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

На 20% більше тестів не завжди на 20% більше якості.

Друге. Це проблема управління. Якщо керівництво хоче 100-відсоткового покриття, вони повинні встановити систему винагород, яка винагороджує 100-відсоткове покриття замість "достатньо гарного, щоб звільнити" 80% покриття.

Додавання QA людей, щоб написати більше тестів, не допоможе багато.

Додавання розробників для написання більше тестів - те, що потрібно, щоб отримати 100% тестовий покрив.

Тестування блоку IMHO не є процесом забезпечення якості. Йдеться більше про пришвидшення розробки (скорочення циклу зворотного зв’язку для розробників). Це має робити людина, яка пише компонент (він же блок), з акцентом на використання компонентів (іншим розробником).

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

І те й інше можна зробити TDD.

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

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

Якщо вам потрібно щонайменше 80% покриття, вам потрібно зробити пару речей:

• Надайте своїм розробникам необхідні інструменти, щоб визначити, який рівень покриття вони мають - і переконайтеся, що це яблука для яблук. Існує кілька способів вимірювання покриття.
• Надайте нагороду / стимул за здійснення цього подвигу. Програмісти збираються робити лише те, що, на їхню думку, окупиться. Якщо 50% покриття достатньо хороше, щоб забезпечити якість та виконати всю роботу, це те, що вони будуть робити.

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

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