TDD чи не TDD: інтерв’ю з керівником back-end команди – Web-systems
Технології

TDD чи не TDD: інтерв’ю з керівником back-end команди

28 вер 2018
Автор:Web Systems
7

Блог - TDD чи не TDD: інтерв'ю з керівником back-end команди : image-Що таке test-driven development, або TDD? Почнемо з загального визначення і на цьому закінчимо формальну частину статті. TDD – техніка розробки програмного забезпечення, згідно з якою, написанню коду передує написання тестів для його перевірки. Про це ви прочитаєте в будь-якій енциклопедичній статті. У цій публікації ми розповімо про техніку в дії. У кожного практикуючого розробника свій підхід, відповідно способів застосувати теорію на практиці стільки ж, скільки і розробників у цьому світі. Про те, як ми реалізуємо TDD на наших проектах розповість Team Lead Back-end розробників Олександр.

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

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

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

Як можна написати тест для функціоналу, якого ще не існує? Від чого відштовхується розробник, який працює за схемою TDD в написанні тестів? Багато хто погодиться, що test-driven development – це подвійна робота. Спочатку потрібно продумати і написати тести, потім написати код. У чому сенс?

Писати тести після того, як був написаний код – це як описувати вимоги до продукту, після того, як він вже був реалізований. Test-driven development змушує визначитися, що ти хочеш отримати від того чи іншого шматка коду. Спочатку ви пишите тести, які потрібні вам для вирішення конкретних вимог, а потім код, необхідний для того, щоб пройти всі тести. Таким чином, ця методика ще й захищає вас, зокрема від написання необдуманого й малофунціонального коду, і як результат – від поганої архітектури самого проекту. Тому не згоден, що test-driven development – подвійна робота.

Не бу стверджувати, що TDD скоротить час розробки, можливо, навіть навпаки. Але TDD дає нам чистий код, який працює – ось, що дійсно має значення. Заощадимо час на етапі правок.

Чи не сковує дії такий підхід в розробці?

Взагалі потрібно розуміти, що будь-яка методика – це лише “рецепт”. Приготувати страву можна абсолютно по-різному. Так і з TDD, хтось сліпо слідує сценарію, а хтось проявляє творчість. Думаю, мало хто використовує цей підхід “як книжка пише”. Ми адаптували TDD під себе, і під мінливі вимоги бізнесу. Не завжди виходить спочатку писати тести, особливо в умовах частих змін бізнес-логіки нашого додатку. На мій погляд, найкращий аргумент на користь TDD полягає в тому, що ви отримуєте набір тестів, які ви можете запустити, коли нарешті дістанетеся до фази рефакторингу й обслуговування вашого проекту. Це найголовніше. Написати тести можна в будь-який час, а не сліпо слідувати методології. Але писати їх потрібно!

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

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

Як виглядають ці тести? Яким чином влаштовано test-driven development на твоїх проектах?

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

Якщо підсумувати, то в чому цінність техніки test-driven development? Її потрібно застосовувати до всіх проектів?

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

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

Вам також може бути цікавою наша стаття про автоматичне тестування “Автотестування великих веб-проектів: для чого і як ми пишемо автотести”.

Хочете замовити проект?
Дзвоніть +38 067 98 00 900
або заповніть форму

Почати проект
Від студента-практиканта до back-end розробника, або як я почав працювати в IT-компанії: інтерв’ю
Блог

Від студента-практиканта до back-end розробника, або як я почав працювати в IT-компанії: інтерв’ю

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

Що таке хороший веб-дизайн?
Блог

Що таке хороший веб-дизайн?

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

Ура! Ми чемпіони! Кубок StartUP Football 3×3 наш!
Компания

Ура! Ми чемпіони! Кубок StartUP Football 3×3 наш!

Наші хлопці молодці! Пишаємося і радіємо за переможців!