Як професійний розробник, чи допустимо не писати одиничні тести? [зачинено]

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

Щоб перевірити що?

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

Тепер, як розробник, ви повинні знати, як писати одиничні тести та де вони потрібні.

Теорія

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

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

Ще раз, це не гарантує, що вся система запрацює, але спрощує тестування.

TDD не є вимогою сама по собі. Це спрощує кодування, змушуючи розробника відповісти спочатку "що я насправді збираюся кодувати?".

Витрати

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

Скажімо, ви зробили помилку у своєму коді та виявили та виправили це в той же день. Вартість $ X .
Припустимо, помилка залишається не виявленою і переходить до щотижневої внутрішньої збірки. На щастя, QA виявив це, підняв помилку в програмі відслідковування помилок, питання було предметом 5-хвилинної дискусії на зустрічі 5 людей і т. Д. Нарешті, ви це вирішите. Вартість - це сума робочої сили, витрачена всіма, і в цьому випадку вона може становити $ 3 * X.
Що робити, якщо помилка перейшла до бета-тестування та залучила більше людей? Давайте скажемо, $ 10 * X .
Якщо він довгий час залишається невиявленим, пішов до 1000 клієнтів (сподіваємось, не мільйон!), 10 з них виявили це, вони підняли дискусію з вашим обслуговуючим персоналом, дехто може зателефонувати з вашим начальником, ваші товариші по команді намагаються відтворити це і т. д. і т. д. Нарешті, помилка повертається до вас, і ви її виправляєте. Скільки, загалом? Ну більш ніж $ 50 * X .

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

Професіонали

• Тестові одиниці дозволяють розробнику краще кодувати . Так просто.
• Вони дозволяють заощадити ваш час;
• Вони зменшують витрати;
• Блок тестів живе разом з кодом, який вони перевіряють. Після будь-якого запиту на зміни (що відбувається постійно), тести адаптуються.

Кон

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

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

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

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

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

TDD - це не лише спочатку написання тестів. Йдеться про те, щоб переконатися, що ваш код легко перевірити. І частіше за все легко перевіряється код також легше читати / налагоджувати / підтримувати. Частіше за все легко перевіряється код також дотримується шаблонів та принципів ОО, таких як SOLID. Я зауважу, що як професійний розробник ваш код завжди повинен писатися саме так.

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

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

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

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

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

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

Тож, мабуть, це буде якась функція

• Розмір / оборот команди
• Бажаний термін зберігання програми
• Програма та як критичні збої
• Час, передбачений для впровадження кращих практик щодо графіка розвитку
• Здатність до команди (це не означає бути хорошим програмістом, це означає, що ви не повинні писати одиничні тести, але команда без молодших розробників може мати можливість летіти за сидіння штанів з більшим успіхом)

Існує безліч ситуацій, коли не можна писати одиничні тести. TDD зараз "в", але це не срібна куля.

Професійно писати випробування на одиничні модулі, які заощадять ваш час та сльози!

Існує misconception that Unit test finds bugs. Добре, що це просто НЕ справедливо для всіх випадків. Тестування блоку не полягає у пошуку помилок або виявленні регресій. Це за визначенням examine each unit of your code separately. Але коли ваша програма працює реально, всі ці підрозділи повинні працювати разом, і ціле є більш складним і тонким, ніж сума його незалежно перевірених частин.

Таким чином, мета тестування підрозділу (в процесі TDD) полягає в надійному проектуванні компонентів програмного забезпечення.

Редагувати: Є один виняток, коли одиничні тести дійсно виявляють помилки. Це коли ви рефакторинг або реструктуризуєте код підрозділу, але без сенсу змінювати його поведінку. У цьому випадку одиничні тести часто можуть повідомити, чи змінилася поведінка підрозділу.

Як професійний розробник, чи допустимо не писати одиничні тести?

Ні.

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

Наскільки ретельними повинні бути ці одиничні тести?

Ось лакмусовий тест: Якщо QA виявить помилку у вашому коді, чи буде вам зручно використовувати тест-одиницю, щоб довести свою належну старанність своєму начальнику?

Якщо ваша відповідь - «Ні», то вам слід скласти кращий тест (або тести).
Якщо ваша відповідь - так, то ваш код готовий до перевірки.

Як професійний розробник, чи допустимо не писати тести автоматизованих одиниць?

Так.

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

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