Как я раньше видел тесты в интерфейсе
6 лет назад испытания для меня были чем-то далеким. Раньше я разрабатывал несколько страниц, работая для агентств - времени было очень мало, и все нужно было делать быстро. Я даже не могу сосчитать количество посещенных мной горячих сайтов. В то время я видел несколько статей о том, как тестировать свой JavaScript-код, но признаюсь, что эта тема никогда не вызывала у меня интереса. Я считал, что делать что-то без тестов будет быстрее (просто зайдите в браузер и обновитесь, чтобы «проверить» результат).
Шло время, и я начал взрослеть в своей карьере: приближались более серьезные проекты, и сложность возрастала. Итак, однажды я попытался устроиться на работу в чужую компанию, и в моей жизни началось «время шока». В 2013 году многие говорили об AngularJS и преимуществах тестирования кода. Каждая компания просила меня присылать кодовые задания с тестами. С того времени я изменил свое мышление и начал понимать, что тесты - это больше, чем «какие-то утверждения». Таким образом, все стало проясняться.
Хорошо, мне нужно это выучить!
Если вы только начинаете заниматься программированием, часто думают, что тесты не нужны или требуют много усилий. Я сам придерживался этого мышления много лет. Когда я наконец увидел необходимость тестирования своего кода, я начал искать, как это сделать, и это было не так просто, как сейчас. Сегодня, когда я вижу такую простую и понятную установку, как Jest, я начинаю задумываться, почему многие разработчики этого не делают. Моя первая установка или набор тестов стоила мне целого дня на настройку препроцессоров. Я использовал Jasmine с Grunt, и это было нелегко. Часто некоторые люди сдаются на уровне настройки. Я говорю это, потому что чуть не упал.
После долгой и сложной настройки я наконец все сделал \ o /. «Хорошо, теперь у меня есть набор тестов, но как я буду тестировать свой код?». Да! Тяжелые времена еще не прошли. Я думаю, что основная трудность во внешнем интерфейсе для тестирования вашего кода состоит в том, чтобы различать: что такое «общедоступные методы», что я должен тестировать, и некоторые другие вопросы, которые могут возникнуть. Я начал тестировать что угодно, любой метод, любой «компонент», любой интерфейс и т. Д. Я думаю, было бы хорошо для меня разделить вещи и знать, что действительно необходимо, чтобы гарантировать в наших тестах, что все работает нормально.
Но в чем причина его тестирования? Так просто, не правда ли?
После этой начальной настройки я был готов приступить к тестированию своего кода. Да, я начинал новый шаг в своей жизни, и первый вопрос, который у меня возник, был: «Посмотрите на эту функцию, очевидно, что она будет работать, зачем мне здесь что-то тестировать?». Ага, мужик, тебе нужно это проверить! Еще не убедили? Хорошо, позволь мне показать тебе.
Представим, что вы работаете над большим проектом с множеством функций. Как вы можете гарантировать, что все будет работать безупречно всегда? Не имеет значения, является ли тема функции справочной функцией, например:
function sumFunction (a, b) {
return a + b;
}
sumFunction (1, 2);
Совершенно очевидно, что результатом будет 3, но если эта функция получит новое условие, например:
функция someFunction (a, b) {
if (a ›b) {
return (a * b) + b;
}
вернуть;
}
someFunction (5, 10);
Вы знаете конечный результат - я думаю, он у вас в голове. Однако, если кто-то передаст в качестве первого аргумента массив, а не число, что произойдет? Зависит от вашей цели! Тесты гарантируют, что все условия и поведение будут работать должным образом. На этом этапе очень важен образ мышления разработки через тестирование (TDD), потому что вы можете начать описание поведения, а затем начать кодировать сам этот метод. Кажется, легко, не так ли?
Разработка через тестирование (TDD) - еще одна стена, с которой я столкнулся на своем пути. Честно говоря, начало действительно непростое. Каждый программист любит быстро кодировать и реализовывать логику и решать проблемы как можно скорее. Изменить это мышление и начать с тестов, а не с логической реализации, чрезвычайно сложно. Нам нужно много настаивать, чтобы переосмыслить этот стиль работы. Необходимо много работать и упорствовать, чтобы это изменить.
На моем пути большой и сложный проект
Когда я начал работать с продуктом, а не только с отдельными сайтами, моя концепция начала меняться. Представьте себя: группа команд, работающих с множеством функций одновременно, и ничто - или почти что угодно - не может потерпеть неудачу. Как можно гарантировать, что все будет работать в идеальной гармонии долгое время? Это сложно, но это реальность для многих компаний, которые работают с технологиями, особенно в среде SaaS.
Моя первая серьезная задача в RDStation Marketing
А теперь пора рассказать вам несколько слов о личной истории в Resultados Digitais. Одна из первых серьезных проблем, с которыми я работала здесь, заключалась в том, чтобы справиться с Email Builder (названным «Lego»), поскольку он был создан с использованием EmberJS. Следуя образу мышления Ruby on Rails, EmberJS поощряет вас тестировать все: модели, маршруты, компоненты, контроллеры и т. Д. Всегда выполняйте модульные тесты (методы и логики) и интеграционные тесты (спецификации, развивающие логику методов и их поведение на уровне представления). Признаюсь, у меня был большой опыт с этим, потому что в то время все стало обретать смысл, и преимущества тестов оказались более очевидными.
Новая автоматизация рабочего процесса
Я до сих пор не рассказал вам об этом «большом и сложном» проекте. После долгого времени работы в Email Builder Team (Gorillaz) меня пригласили поработать с другой функцией моей компании, это была новая автоматизация рабочего процесса электронной почты - большой и надежный проект с использованием VanillaJS (да, без JavaScript-фреймворков), графов отношений , перетаскивание, события, компоненты и т. д. У нас был небольшой крайний срок, чтобы запустить его в производство: что-то около 2 месяцев и много работы.
Во-первых, небольшой контекст: автоматизация рабочего процесса используется для создания различных маршрутов, по которым потенциальный бизнес-клиент будет проходить в зависимости от своих действий (например: открыть электронное письмо, щелкнуть в электронном письме с призывом к действию, преобразовать в форму целевой страницы , так далее). Для входящего маркетинга это действительно имеет большой смысл, поскольку действия лида меняют шаги, пока не достигнут дна фунила. Если вы хотите узнать больше о концепциях входящего маркетинга, вы можете проверить здесь.
Возвращаясь к программированию, главная цель состояла в том, чтобы согласовать события перетаскивания и перетаскивания со структурой нашего графа. Если пользователь перемещает шаг со 2 на 4, нам нужно внести некоторые изменения, чтобы поведение сохранялось, например:
Мы создали 3 основные функции, которые отвечают за: создание, перемещение и удаление в зависимости от действий, совершаемых пользователем при использовании функции перетаскивания (см. Пример ниже). Независимо от действий, поддержание поведения заставило нас тратить много часов на рисование и сжигание нейронов со сложной логикой, используя только бумагу и карандаши. На этом этапе тесты стали приобретать особый смысл, поскольку нам нужно поддерживать все поведения, возникающие при большом количестве действий и различных сценариях.
Это был всего лишь обзор проблемы, но я ожидаю, что он покажет вам важность тестов в жизненном цикле продукта, особенно сложных. В капле: «Ни тестов, ни доставки». Конечный результат всей этой сложной логики вы можете увидеть ниже:
Заключение
Я думаю, что основная цель этой статьи - предложить вам отказаться от текущего сценария и подумать масштабно и лучше! Возможно, когда-нибудь в своей карьере вы будете работать над большим и сложным проектом, требующим большой ответственности и сжатых сроков. Качество - это главный образ мышления, который вам нужно иметь в виду, ваши реализации должны работать так, как ожидалось, чтобы охватить все возможные сценарии - предотвращение чего-то вроде инцидента (серьезной ошибки) в производственной среде.
Начни тестировать сегодня! Неважно, имеет ли ваш проект 1% покрытия, начните с маленьких шагов и неуклонно продолжайте свой путь. У вас есть множество технологий, которые позволяют сократить время настройки тестов. Нет оправдания, чтобы не начать сейчас, тесты - это старая практика, и не применять ее - вопрос этический. Если вам нужно узнать больше об опыте, описанном выше, отправьте мне электронное письмо или позвоните мне в LinkedIn.
В заключение приглашаю вас посмотреть серию видеороликов о тестах от Fun Fun Function (нажмите здесь).
Особая благодарность LeoSL, Жоао Паулу Барбоса, Генриху Мораесу, Саймону Крусу, Фабрицио Дароши Джуниор и Жоао Хорнбургу за их поддержку.
Спасибо! ;)
