Чому тестова розробка (TDD) - найкращий спосіб для надійного кодування.

Спочатку напишіть одиничні тести, потім введіть код.

Іміджеві кредити: Pexels.com

Деякі роки тому, коли я вперше почув про "Тест-керований розвиток", я був скептичним.

Сама думка "спочатку написати тестові одиниці, потім написати код" була для мене химерною.

Чому б цього не було? Спочатку написати свої тести? Хто б робив подібну тугу річ?

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

Тому я порадився зі своїм другом, який показав мені основний приклад.

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

Код для класу був таким:

ВИЗНАЧЕННЯ КЛАС lcl_sum.
ГРОМАДСЬКИЙ РОЗДІЛ.
МЕТОДИ: ІМПОРТИРУВАННЯ СУМКА iv_1 ТИП i
ПОВЕРНЕННЯ ЗНАЧЕННЯ (rv_sum) ТИП i.
ENDCLASS. «ВИЗНАЧЕННЯ lcl_sum
*
ПОЧАТОК ВИБОРУ.
* Тут поки нічого
*
*
КЛАС lcl_sum ВПРОВАДЖЕННЯ.
МЕТОД СУМ.
rv_sum = iv_1 * iv_1. "Навмисна помилка (множу замість додавання)
ENDMETHOD. «Сума
ENDCLASS. "ВИКОНАВАННЯ lcl_sum

Налаштування тестового класу

Тепер створіть клас, який виконує роль тестового класу. У SAP вам потрібно буде додати ключове слово ДЛЯ ТЕСТУВАННЯ при визначенні класу. Це доповнення відокремлює цей клас від виробничого коду.

КЛАС lcl_test ВИЗНАЧЕННЯ ДЛЯ ТЕСТУВАННЯ
ГРОМАДСЬКИЙ РОЗДІЛ.
МЕТОДИ: m_sum ДЛЯ ТЕСТУВАННЯ.
ENDCLASS. "Lcl_test ВИЗНАЧЕННЯ
*
КЛАС lcl_test ВПРОВАДЖЕННЯ.
МЕТОД м.сум.
ENDMETHOD. “M_sum
ENDCLASS. "ВКЛЮЧЕННЯ lcl_test

Впровадження методу тестування

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

Виходячи зі значення Dummy, метод надішле вам результат - фактичний результат від методу. Виходячи з значення манекена, ви знаєте, яка була б очікувана цінність. Наприклад Якщо ви передасте номер 3 методу SUM, це дасть вам результат 6, оскільки він додає до рівня 3.

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

КЛАС lcl_test ВПРОВАДЖЕННЯ.
МЕТОД м.сум.
ДАНІ: o_cut ТИП СПОСОБУ lcl_sum.
ДАНІ: lv_result ТИП i.
*
СТВОРИТИ ОБ'ЄКТ o_cut.
lv_result = o_cut-> сума (3).
*
cl_aunit_assert => assert_equals (
EXP = 6
act = lv_result
msg = "щось неправильне у виході"
).
ENDMETHOD. “M_sum
ENDCLASS. "ВКЛЮЧЕННЯ lcl_test

Результати одиничного тестування

Це говорить мені про те, що у впровадженні методу виробництва щось не так.

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

Мене причепили до TDD. Влучне обмацування було б правильним словом.

Дивовижним було сильно скорочений час циклу розробки та тестування.

Мені звикли писати код протягом більшої години, перш ніж спробувати скласти або запустити його. Але тут код виконувався і перевірявся кожні 2 хвилини або близько того.

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

Ви додасте трохи до коду тестового випадку. Ви додаєте трохи до виробничого коду. Два потоки коду одночасно переростають у взаємодоповнюючі компоненти. Випробування відповідають виробничому коду так, як антитіло відповідає антигену.

Цей захід заважає розробникам писати непотрібний код, який не відповідає даному тесту.

І весь цей інтегрований підхід пропонує розробнику цілий ряд переваг.

Ви виправляєте поганий код, не порушуючи нічого.

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

· «Це безлад. Я думаю, я мушу якось це виправити ».

· "Я цього не торкаюся".

У будь-якому випадку є елемент страху. Насправді невизначеність.

Що робити, якщо мій код порушує існуючий функціонал?

TDD допомагає вам точно подолати цю невизначеність.

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

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

TDD застосовує документацію.

Дік Брендон вдарив його ударом по нігтю, коли спостерігав.

“Документація - це секс; коли це добре, це дуже, дуже добре, а коли це погано, то краще нічого ».

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

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

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

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

TDD допомагає в кращому дизайні

Основна умова TDD полягає в тому, що ви повинні написати свої тестові приклади, перш ніж писати код.

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

Це створює кращий, відокремлений дизайн, в якому ви маєте кращий контроль над речами в міру розвитку коду.

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

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

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

І нарешті, TDD дотримується кращих методів кодування.

TDD просуває хороші принципи кодування, включаючи DRY, KISS, YAGNI та SOLID.

Принцип DRY (Don’t Repeat Yourself) говорить розробникам уникати повторення одного і того ж коду в різних частинах однієї системи, тому його також іноді називають принципом DIE (дублювання - зло). DRY рекомендує розробникам використовувати класи та функції, щоб інкапсулювати функціональність системи та підтримувати послідовну базу даних коду.

Принцип KISS (Keep it Simple, Stupid!) Радить розробникам не винаходити колесо, а будувати прості та чіткі архітектури. Суть KISS полягає у тому, щоб уникнути надмірно розроблених рішень.

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

SOLID складається з п'яти принципів в одному: одна відповідальність, відкритість-закриття, заміна Ліскова, сегрегація інтерфейсу та інверсія залежності. Якщо коротко сказати, SOLID заявляє, що дотримання цих принципів полегшує обслуговування та тестування програм.

Коротше кажучи, TDD допомагає створювати елегантний та простий код, який легко обслуговувати.

Як влучно сказав Роберт Мартін.

"Чистий код завжди виглядає так, що його написав хтось, хто дбає".

Список літератури

Екстремальне програмування: Кент Бек.

Agile Software Development: Роберт Мартін

Реконструкція: Мартін Фаулер

Про автора-:

Раві Раджан - глобальний менеджер ІТ-програм, що базується в Мумбаї, Індія. Він також завзятий блогер, письменник поезії Хайку, ентузіаст археології та маніяк історії. Спілкуйтеся з Раві на LinkedIn, Medium та Twitter.

Ця історія опублікована в найбільшій підприємницькій публікації "Середній бізнес" ("Startup"), а за нею - +438 678 осіб.

Підпишіться, щоб отримувати наші основні історії тут.