Как я продаю TDD другим разработчикам

Как я продаю TDD другим разработчикам

Потому что не каждый разработчик улыбнется вам, когда вы произнесете три волшебных буквы.

За последние 7 лет я разрабатывал приложения для iOS для пары разных компаний с множеством разных разработчиков с разным опытом. Были некоторые очень специфические проекты, в которые было трудно добавлять функции, поддерживать кодовую базу, исправлять дефекты и рефакторинг.

У этих проектов было одно общее - ни в одном из них не было тестов, и ни один разработчик не поддерживал их, либо потому, что команда не знала, как это делать, либо никогда не слышала о преимуществах разработки через тестирование.

Но всегда есть проект по изменению мировоззрения. Тот, который позволяет вам общаться с более опытными людьми, изучать новые технологии и новые техники. К счастью, это случилось со мной пару лет назад, когда клиенту потребовалась вся команда, чтобы начать разработку функций с использованием TDD.

С этого момента в моей карьере не было ни одного проекта без тестов. Не имеет значения размер проекта, команда или заказчик. TDD теперь является частью моего ремесла, и я поставил перед собой задачу распространить информацию среди разработчиков, с которыми я работаю, а также, почему бы и нет, среди сообщества.

Что ж, если вы читаете эту статью из-за аббревиатуры TDD в названии, думаю, мне не нужно убеждать вас в том, почему вы должны ее принять. Моя цель в этой статье - попытаться показать вам, как продать идею использования разработки через тестирование вашей команде. Потому что они настоящая аудитория, и они должны купить идею использовать ее так же, как я сделал это несколько лет назад.

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

Витрина

Из-за условий конфиденциальности проекта я буду использовать другое название компании, а также не настоящие данные, чтобы проиллюстрировать реальность.

Я назову это компанией Burger Chalet 🍔 🏠.

Особенность

Одна из основных функций приложения Burger Chalet - это возможность добавлять различные ингредиенты в свои гамбургеры. Вы можете настроить его, добавив ингредиенты слева, справа или целиком.

Итак, вот как выглядит пользовательский объект бургера:

На основе такого JSON запрошенная функция заключалась в описании бургера в корзине приложения в каком-то формате toString:

Сырный бургер с говяжьей котлетой, салатом, томатным соусом (слева), солеными огурцами (справа) и экстра пепперони.

Обратите внимание, что здесь есть некоторые правила, такие как добавление 'с' и 'и' к первому и последнему ингредиентам, а также добавление 'Экстра'. , '(справа)' или '(слева)' в зависимости от списка ингредиентов. Также есть порядок отображения, в котором должны быть перечислены ингредиенты.

Кажется, это очень приятная и простая в реализации функция. Вы можете сразу же начать писать эту функцию и протестировать поток, чтобы увидеть, работает ваш код или нет. Все просто, правда?

Проблема в следующем: чтобы добраться до точки, в которой вы действительно проверяете, работает ли ваш код, вам сначала необходимо:

Обычный подход:

1- Войдите в систему
2- Загрузите меню магазина
3- Выберите категорию продуктов (в данном случае это гамбургер)
4- Выберите гамбургер
5- Настройте его
6- Добавьте в корзину
7- Проверьте правильность описания. (Здесь вы на самом деле проверяете, работает ли ваш код)

В нормальной сети получение кода может занять до 2 минут.

А теперь представьте, что вы собираетесь протестировать его пару раз в нескольких разных сценариях, с разными комбинациями ингредиентов, недопустимыми сценариями и так далее.

Ага, попрощайся с днем! Возьмите большую кружку кофе и начните разбивать клавиатуру, надеясь закончить эту задачу к EOD сегодня 👎😞☕️

Или вы можете сделать это:

Подход TDD:

1- Проведите приятную короткую сессию, чтобы выполнить TDD, чтобы получить код, который подходит для всех возможных сценариев, с достаточной уверенностью для рефакторинга в любое время.

И угадайте, что: буквально СЕКУНДЫ, чтобы увидеть, работает ваш код или нет. Разве это не здорово?

Все самое интересное происходит в функции describeBurger. Здесь мы собираемся написать весь код, который должен передавать сценарии.
И каждый раз, когда мы нажимаем command + S, наш набор тестов запускается снова (потому что мы используем Jest с Watch Mode), что дает нам мгновенную обратную связь, которая говорит нам, работает ли наш код.

Глядя на обе ситуации, становится просто решить, какой подход выбрать:

1. Потратьте 2 минуты на проверку ваших изменений для каждого возможного сценария.
2: Потратьте секунды на одновременную проверку ваших изменений для максимально возможного количества сценариев.

Вы можете прочитать то же самое, что и:

Вы можете украсть у своего клиента, потратив гораздо больше времени на разработку функции, или выбрать написание модульных тестов и отработку TDD, чтобы убедиться, что: ваш код работает, вы и ваша команда сможете улучшить код, рефакторируя его всякий раз, когда вы хотите и тратите меньше времени на выполнение тех же функций.

Найдите свой пример

Очевидно, что приведенный выше сценарий является очень хорошим примером для моей команды из-за его контекста . В идеальном мире вам нужно будет найти эту повторяющуюся задачу в своем проекте. провести такое же сравнение и показать его своим разработчикам.

Продажа TDD - это поиск возможностей, в которых вы можете продемонстрировать их, сэкономив значительное количество времени. Если вы можете предвидеть, что выполнение определенной задачи будет повторяющимся процессом, дерзайте. Вероятно, это тот пример, который вы ищете.

Я видел больше людей, заинтересованных в TDD, после презентаций об этой витрине. Попробуйте это со своей командой, компанией и посмотрите на результат. Бьюсь об заклад, что по крайней мере один человек собирается начать создавать запросы на слияние с модульными тестами. И если это произойдет, гордитесь этим и продолжайте подталкивать своих товарищей по команде еще дальше, говоря о BDD, отчетах об охвате тестирования, тестировании пользовательского интерфейса и т. Д.

И последнее, но не менее важное: если вам не удалось найти хороший пример и вы хотите увидеть модульные тесты в своей кодовой базе, начните делать это самостоятельно. Проявите некоторое уважение к своему клиенту, проекту, над которым вы работаете, и своим коллегам. Кто-то в конечном итоге последует за вами и тоже начнет писать модульные тесты.

Лучшее, что вы можете сделать, - это показать пример.

Спасибо.

Кредиты:

📖 Рецензенты: Фабио Белтрао, Тайнара Шпехт и Пауло Вироте.
📸 Изображение на обложке: Тьяго Винклер
🤓 На фото: Афонсу Феррер, Энгель Флорес, Мария Луканова, Виктория Айелло и Пауло Вироте.

Афонсу, Энгель и Мария участвуют в нашей программе стажировки в Isobar IWS Brazil. Вы также можете прочитать Статью Энгеля о программе стажировки.

Здесь вы можете найти работу в Isobar IWS Brazil.