Tdd что это

Что такое TDD — все о test driven development

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

Разработка программ с помощью TDD подхода

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

На изображении снизу представлен процесс разработки программ методом TDD в виде блок-схемы.

Рассмотрим назначение каждого из блоков схемы.

Написание тестов

Тесты представляют собой программные единицы, реализующие проверку соответствия кода программы требованиям к функциональности, сформулированным в техническом задании (ТЗ). Тесты целесообразно создавать на основе ТЗ, созданного заказчиком проекта. В таком случае их проверка на выполнимость может осуществляться на стороне заказчика. Для их создания, а также автоматизации запуска, как правило, используются те же Фреймворки, что и для создания программ. Тесты пишутся для небольших, наиболее критичных участков программы, подверженных частым изменениям. Метод TDD изначально рассматривался, как наиболее подходящий для таких участков и, поэтому, получил название «экстремальное программирование».

Проверка выполнимости теста

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

Написание кода программы

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

Комплексная проверка

Комплексная проверка готового кода на соответствие требованиям тестов. На этом этапе осуществляется запуск тестов для готового участка кода программы и выявление «нестыковки» при их выполнении. В случае, если тесты успешно выполняются, код передаётся на следующий этап обработки – рефакторинг. Если нет, то код возвращается на доработку.

Оптимизация кода программы

Цель этого этапа – оптимизировать код изнутри, оставив его «внешнюю» функциональность. Сюда относится, в частности, уменьшение избыточности кода до допустимого уровня и другие операции, связанные с его оптимизацией. Этот процесс принято называть рефакторингом кода программы, без которого программа не будет оптимальной. После выполнения оптимизации, процесс повторяется снова, то есть, количество итераций будет таким, чтобы, в конечном счёте, обеспечить выход оптимизированного программного модуля с нужной функциональностью.

Преимущества использования TDD

Среди преимуществ использования метода TDD для создания программного обеспечения, можно выделить следующие:

• Использование тестов снижает количество ошибок в коде, а значит, уменьшается время его отладки и, в конечном счёте, время разработки программы.

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

• Тесты позволяют производить рефакторинг кода, исключая при этом его повреждение.

• Применение методики способствует улучшению основных характеристик кода – модульности, гибкости и расширяемости.

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

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

Недостатки использования метода TDD

Как и любые методы или подходы к программированию, рассматриваемый метод также имеет недостатки. Выделим некоторые из них:

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

• Требуется дополнительное время на разработку и поддержку тестов. Поэтому перед применением методики необходимо обосновать и доказать целесообразность и эффективность её использования в конкретной ситуации.

• Увеличиваются накладные расходы на создание программ.

Что такое TDD (test-driven development)

TDD существует с 1999 года и является методом разработки программного обеспечения, основанном на тестировании. В 2003 году американский разработчик Кент Бек «заново открыл» TDD и применил его как способ создания простых конструкций и внушающих доверие. На сегодняшний день, TDD – это процесс разработки программного обеспечения, использующий очень короткий цикл обратной связи, при котором разработчики:

1. Создают тест, который не может быть пройден.
2. Пишут рабочий код, который пройдёт тест.
3. Делают рефакторинг кода, написанного на втором шаге, используя созданный тест доводят код до совершенства.

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

Оглавление

• Развитие TDD
• Что же такое Test Driven Development (TDD)?
• Рефакторинг
• Красный, зеленый, рефакторинг
• Какие существуют виды тестов?
• Инструменты
• Платформы и инструменты для тестов TDD для проектов PHP
• Преимущества TDD
• Недостатки тест-ориентированной разработки
• Когда применяется TDD
• Измерение тестируемости с помощью покрытия кода
• Практика использования TDD
• Резюме

Развитие TDD

Подход TDD отличается от других методов тем, что он объединяет программирование с написанием тестов самим разработчиком. Эта концепция возобновляет всеобщее уважение к тестам, созданным программистом.

1976 год. Публикация Гленфорда Майерса «Надежность программного обеспечения», которая определяет, как аксиому то, что программист никогда не должен тестировать свой собственный код (Dark Age of Developer Testing).

1990 год. В дисциплине тестирования преобладают методы «черного ящика», в частности, в форме инструментов тестирования «поймай и повтори».

1991 год. Независимое создание тестовой среды в Taligent поразительно похожей на SUnit.

1994 год. Кент Бек пишет тестовый скелет SUnit для Smalltalk.

1998 год. Статья об экстремальном программировании упоминает, что «мы обычно пишем тест в первую очередь».

С 1998 по 2002 год. Test First преобразован в Test Driven.

2000. Автоматизированные тесты – инновационные методы, разработанные в этот период.

2003 год. Публикация Кента Бека «Разработка через тестирование: на примере».

В 2006 году TDD превратился в признанную технику, которая стала поощрять дальнейшие инновации, такие как разработка на основе приемочных испытаний (ATDD) и развитие на основе поведения (BDD).

Что же такое Test Driven Development (TDD)?

Разработка через тестирование – это подход к программированию, при котором программирование должно вестись на основании тестирования, а не наоборот. При традиционном подходе к разработке программного обеспечения заказчик выдвигает требования к программе. Затем разработчик создает код, который соответствует критериям приемлемости пользовательской истории. Затем код будет объединен и протестирован тестировщиком в среде QA или SIT. Тестер может найти дефекты. В этом случае код отправляется на доработку.

Существует цикл: написать код, запустить тесты, исправить код. Test Driven Development переворачивает этот цикл с ног на голову. В нем говорится, что мы должны сначала создать тесты, затем написать код, после чего исправить код.

В Test Driven Development сначала пишется и запускается тест, затем пишется код (до тех пор, пока он не пройдёт тест), а затем код реорганизуется. Это называется рефакторинг.

Рефакторинг

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

Функциональность может быть проверена во время рефакторинга путем многократного запуска тестов.

Рефакторинг может значительно улучшить читаемость кода, устранить дублирование, облегчить техническое обслуживание и расширение системы в будущем. Поскольку это небольшие, определенные и контролируемые изменения, их также можно автоматизировать с помощью инструментов рефакторинга, которые уже интегрированы во многие популярные среды разработки, что значительно повышает производительность труда разработчиков. Основной каталог модификаций – рефакторинг можно найти в отличной книге Мартина Фаулера «Рефакторинг».

Красный, зеленый, рефакторинг

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

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

Затем пишется код, пока тесты не будут пройдены (зеленый). На зеленой стадии добавляется минимальный объем производственного кода, необходимый для прохождения тестов. Затем код дорабатывается. То есть его улучшают, не влияя на поведение. И поскольку тесты уже готовы, то можно быстро их снова запустить и удостовериться, что рефакторинг не повлиял на функциональность.

Кент Бек, в eXtreme Programming (XP) (Beck 2000), определяет два простых правила для TDD:

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

Бек объясняет, как эти два простых правила генерируют сложное индивидуальное и групповое поведение:

1. Разрабатывается работающий код, обеспечивающий обратную связь между решениями.
2. Программист пишет свои собственные тесты, потому что не может ждать 20 раз в день, чтобы кто-то другой написал их для него.
3. Среда разработки должна быстро реагировать на небольшие изменения (например, нужен быстрый компилятор и набор регрессионных тестов).
4. Проекты должны состоять из множества тесно связанных между собой, чтобы облегчить тестирование (это также облегчает эволюцию и обслуживание системы).

Чтобы эффективно работать, разработчикам необходимо научиться писать эффективные модульные тесты. Бек считает, что хорошие юнит-тесты:

1. Быстрые. У них короткие настройки, время работы и поломки.
2. Модульные. Легко можно изменить порядок их прохождения.
3. Используют данные, облегчающие их чтение и понимание.
4. При необходимости используют реальные данные.

Какие существуют виды тестов?

Функциональные тесты – они позволяют увидеть функции приложения с точки зрения пользователя. Это означает, что функциональные тесты могут быть своего рода спецификацией для приложения. Среди них:

1. Проверка правильности работы системы на основе черного ящика.
2. Работа в браузере – тестирует поведение системы, запустив ее в браузере и протестировав на реальном веб-сайте.
3. Поведенческий – тестируют поведение объекта путем определения его функциональности.
4. Тесты производительности – тестирование производительности системы при высоких нагрузках

Модульные тесты – тестирование приложения изнутри, с точки зрения программиста. Они тестируют код, выполняя тесты, проверяющие правильность работы библиотечных объектов / модулей / систем.

Цикличные – это непрерывное повторение создания модульных тестов, пока они не будут пройдены.

Эти типы тестов образуют Тестовую пирамиду.

Считается, что большинство тестов должны быть модульными, с меньшим количеством интеграционных тестов и ещё меньшим приемочных тестов. Google рекомендует соотношение примерно 70/20/10.

Инструменты

TDD должен сочетаться с хорошими инструментами. Необходима среда IDE, такая, как Eclipse с собственной поддержкой JUnit. Настоятельно рекомендуется использовать плагины для облегчения управления модульными тестами, такими как MoreUnit и Infinitest. Последний автоматически выполняет все модульные тесты при каждом изменении кода, что уменьшает циклы обратной связи, которые также закладывают основы для непрерывных модульных тестов. С другой стороны, использование шаблонов кода для модульных тестов является важной экономией времени в повторяющемся цикле TDD. На уровне кода для создания удобочитаемых и гибких бизнес-объектов необходим шаблон проектирования Builder.

Платформы и инструменты для тестов TDD для проектов PHP

Phpunit – это ориентированная на программиста платформа модульного тестирования для PHP, основанная на идее, что кодеры должны быстро находить ошибки в новых проектах без регрессии кода в других частях приложения. Используя Phpunit, можно легко проверить, работает ли каждый протестированный модуль так, как ожидалось.

Behat – это фреймворк BDD PHP с открытым исходным кодом, который использует «человеческие» предложения для запуска тестов программного обеспечения. Behat инструмент предложенный StoryBDD. Помогает определить описательные части, их потребности и вложенный в них смысл. Behat предлагает уникальный подход к тестированию.

Codeception – еще один надежный инструмент TDD для PHP. Codeception похож на PHPUnit и Behat, но все его тесты написаны на PHP, что делает процесс разработки более гибким. Во всех тестах Codeception можно использовать переменные и операторы, а также локаторы CSS и XPath.

Преимущества TDD

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

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

Сокращает общее время разработки: практика показывает, что уменьшается общее время разработки проекта по сравнению с традиционными методами написания кода. В то время как общее количество строк кода увеличивается (из-за тестов), частое тестирование исключает ошибки в процессе и выявляет существующие намного раньше, предотвращая возникновение проблем в дальнейшем.

Недостатки тест-ориентированной разработки

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

Не подходит для всех: метод отлично зарекомендовал себя для работы с небольшими проектами или даже с небольшими компонентами или функциями крупных проектов. К сожалению, методика может давать сбои при применении к очень объёмным или сложным проектам. Написание тестов для сложной функции, которую программист ещё полностью не представляет, может быть трудным, и даже невозможным. Написание тестов – это хорошо, но если эти новые тесты не совсем точно соответствуют требованиям функции, они бесполезны (или даже могут активно препятствовать разработке). Более того, некоторые проекты, особенно те, которые используют устаревший код или сторонние системы, просто не поддаются практическим методам. Для них практически невозможно создать тесты, которые должным образом интегрируются с этими системами или с устаревшим кодом.

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

Когда применяется TDD

TDD подходит как для нового программного обеспечения, так и для устаревших систем. Для команды разработчиков, которая имеет дело с существующим устаревшим программным обеспечением, работа начинается исправлением ошибок. Хорошей практикой является то, что для каждой сообщаемой ошибки создаётся тест, который устраняет ошибку, а затем исправляется функциональность. После нескольких итераций команда разработчиков создаёт повторяемый рабочий тест для исправления ошибок. Применяя эту методологию к новым программным приложениям, следует обратить внимание на инструменты тестирования, используемые для стека технологий. Например, при работе в приложении Angular, которое обычно использует среду тестирования Jasmine для модульного тестирования, и при использовании для Angular CLI, модульные тесты создаются вместе с модулями кода. Методология TDD будет заключаться в следующем:

1. Определение части функциональности, которая будет создана с этим компонентом.
2. Создание модульного теста, который не будет сразу настроен на эту часть функций.
3. Тестовый прогон, чтобы подтвердить неудачный тест (здесь может быть полезно оставить тестовый прогон включенным после каждого сохранения исходного файла, что ускоряет процесс).
4. Написание кода в компоненте Angular, который позволит выполнить тест.
5. Внесение изменений рефакторинга для компонента Angular после подтверждения прохождения, используя тест в качестве руководства, чтобы гарантировать, что рефакторинг кода не нарушает функциональность.

Измерение тестируемости с помощью покрытия кода

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

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

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

Практика использования TDD

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

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

Резюме

Разработка через тестирование – это метод, который в настоящее время широко используется и становится все более популярным. Причина его популярности заключается в том, что усилия, необходимые для его освоения, не так велики, как для экстремального программирования, частью которого является TDD. Хотя у разработчика с самого начала должна быть дисциплина для написания и запуска тестов, без него не было бы программирования, управляемого тестами. Из-за своей природы метод может использоваться в сочетании с различными практиками разработки на более низком уровне (например, в течение одной итерации) и даже в более широком спектре проектов.

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

TDD — разработка через тестирование

TDD, test-driven development или процесс разработки через тестирование — это методология разработки программного обеспечения, которая основывается на повторении коротких циклов разработки:

1. Пишется тест, покрывающий желаемое изменение.
2. Пишется программный код, который реализует желаемое поведение системы и позволяет пройти написанный тест.
3. проводится рефакторинг написанного кода с постоянной проверкой прохождения всех тестов.

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

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

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

Сначала пишется тест, который проверяет корректность работы еще ненаписанного программного кода. Этот тест, разумеется, не проходит. После этого разработчик пишет код, который выполняет действия, требуемые для прохождения теста. После того, как тест успешно пройден, по необходимости осуществляется рефакторинг (доработка и переработка) написанного кода, причём в этом случае рефакторинг осуществляется уже под контролем прохождения тестов, что проще и надёжнее.

Цикл разработки по TDD

• Добавить тест для новой (еще не реализованной) функциональности или для воспроизведения существующего бага
• Запустить все тесты и убедиться, что новый тест не проходит
• Написать код, который обеспечит прохождение теста:
• Запустить тесты и убедиться, что они все прошли успешно: прохождение нового теста подтверждает реализацию нового функционала или исправление существующей ошибки, а прохождение остальных позволяет удостовериться, что ранее реализованный функционал работает по‑прежнему корректно.
• Заняться рефакторингом и оптимизацией — улучшение сопровождаемости и быстродействия целесообразно осуществлять уже после того, как получилось добиться проверяемой работоспособности
• Перезапустить тесты и убедиться, что они все ещё проходят успешно
• Повторить цикл

Эта методология позволяет добиться создания пригодного для автоматического тестирования приложения и очень хорошего покрытия кода тестами. ТЗ переводится на язык автоматических тестов, то есть всё, что программа должна делать, проверяется. Также TDD часто упрощает программную реализацию: так как исключается избыточность — если компонент проходит тест, то он считается готовым. Если же существующие тесты проходят, но работает компонент не так, как ожидается, то это значит, что тесты пока не отражают всех требований, а это повод добавить новые тесты.

Архитектура программных продуктов, разрабатываемых таким образом, обычно лучше (в приложениях, которые пригодны для автоматического тестирования, обычно очень хорошо распределяется ответственность между компонентами, а выполняемые сложные процедуры декомпозированы на множество простых). Стабильность работы приложения, разработанного через тестирование, также выше за счёт того, что все основные функциональные возможноси программы покрыты тестами и их работоспособность регулярно проверяется. Сопровождаемость проектов, где тестируется всё или практически всё, очень высока — разработчики могут не бояться вносить изменения в код, если что‑то пойдёт не так, то об этом ещё до релиза сообщат результаты автоматического тестирования.

Статья опубликована в 2014 и была обновлена в 2023 году

Тематические статьи

Стандарты кодирования — залог хорошей сопровождаемости проекта

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

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

методологии разработки
веб-разработка
Статья опубликована в 2014 и обновлена в 2023 году

SOLID — принципы объектно‑ориентированного программирования

SOLID это аббревиатура пяти основных принципов проектирования в объектно‑ориентированном программировании, предложенных Робертом Мартином:

• Single responsibility — принцип единственной ответственности
• Open-closed — принцип открытости / закрытости
• Liskov substitution — принцип подстановки Барбары Лисков
• Interface segregation — принцип разделения интерфейса
• Dependency inversion — принцип инверсии зависимостей

веб-разработка
методологии разработки
Статья опубликована в 2019 и обновлена в 2023 году

Принцип программирования YAGNI — «Вам это не понадобится»

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

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

методологии разработки
веб-разработка
Статья опубликована в 2019 и обновлена в 2023 году

Принцип программирования KISS — делайте вещи проще

KISS — это принцип проектирования и программирования, при котором простота системы декларируется в качестве основной цели или ценности.

Большая часть программных систем необосновано перегружена практически ненужными функциями, что ухудшает удобство их использование конечными пользователями, а также усложняет их поддержку и развитие разработчиками. Следование принципу KISS позволяет разрабатывать решения, которые не обладают этими недостатками: они просты в использовании и в сопровождении.

методологии разработки
веб-разработка
Статья опубликована в 2019 и обновлена в 2023 году

Принцип программирования DRY — don’t repeat yourself / не повторяйте себя

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

Если код не дублируется, то для изменения логики достаточно внесения исправлений всего в одном месте. Также значительно проще тестировать одну (пусть и более сложную) функцию, а не набор из десятков однотипных. При следовании DRY упрощается и повторное использование функций, вынесенных из сложных алгоритмов, что позволяет сократить время разработки и тестирования новой функциональности.

веб-разработка
методологии разработки
Статья опубликована в 2018 и обновлена в 2023 году

Флаги функций (Feature Flags)

Флаги функций позволяют отделить развертывание функций от развертывания кода, обеспечивают возможности для A/B-тестирования и предоставляют механизм быстрого отключения проблемных функций

методологии разработки
Статья опубликована в 2023 году

Модель ветвления Trunk Based Development (TBD)

Trunk Based Development (TBD) или транковая разработка — модель ветвления системы управления версиями, при которой все разработчики работают в одной ветке. Эта модель имеет значительные преимущества с точки зрения совместной работы, качества кода и скорости доставки изменений.

методологии разработки
Статья опубликована в 2023 году

Процессы, необходимые для информационной безопасности

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

Взломы, утечки данных и неработоспособность ключевых систем приводит как к финансовых потерям, так и к репутационным издержкам. Чтобы снизить риски в сфере ИБ стоит внедрять базовые процессы ИБ в разработку, тестирование и системное администрирование.

информационная безопасность
веб-разработка
тестирование
системное администрирование
Статья опубликована в 2020 и обновлена в 2023 году

MVC — модель‑представление-контроллер

MVC — это паттерн проектирования приложений, который разделяет на три отдельных компонента модель данных приложения, пользовательский интерфейс и слой взаимодействия с пользователем.

В парадигме MVC контроллер определяет способы взаимодействия пользователя с приложением, модель — за слой хранения данных и бизнес‑логику, а представление — за пользовательский интерфейс / формат выходных данных. Модификация каждого из этих компонентов либо оказывает минимальное воздействие на остальные, либо не оказывает его вовсе. Это облегчает понимание логики работы системы и упрощает внесение изменений в кодовую базу.

Что такое TDD и BDD на пальцах, и что должен знать о них фронтендер

Постараюсь как можно проще объяснить эти концепции и на примере показать разницу.

❓Что это вообще за буквы

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

*DD (*что-то* Driven Development) — разработка, основанная на чем-то.

TDD (Test Driven Development) — Разработка на основе тестов.

BDD (Behavior Driven Development) — Разработка на основе поведения.

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

❓В чем разница

• TDD хорошо подходит для юнит-тестирования, т.е. для проверки работы отдельных модулей самих по себе. BDD — для интеграционного (т.е. для проверки, как отдельные модули работают друг с другом) и e2e (т.е. для проверки всей системы целиком) тестирования.
• TDD: тесты сразу реализуются в коде, для BDD чаще всего описываются шаги на языке, понятном всем, а не только разработчикам.
• TDD: юнит-тесты пишут сами разработчики. BDD требует объедения усилий разных членов команды. Обычно тест-кейсы (шаги) описываются ручным тестировщиком или аналитиком и воплощаются в код тестировщиком-автоматизатором. В нашей команде мы (фронтенедеры) описываем шаги вместе с тестировщиками, а код тестов пишет фронтенд-команда.
• TDD проверяет работу функций, BDD — пользовательские сценарии.

❓А как выглядит на примере

Давайте возьмем простую задачку. Нам нужно сделать форму, в которую мы вводим возраст котика и его вес, а в ответ получаем, сколько корма котик должен кушать в сутки.

Как подойти к этой задаче, используя TDD подход:

1. Пишем тест, в котором проверяем, что функция getCatFood() возвращает нужные значения в разных ситуациях
2. Проверяем, что тесты упали (кода еще нет)
3. Пишем код функции очень просто — так чтобы тесты прошли
4. Проверяем, что тесты прошли
5. На этом шаге можем задуматься о качестве кода. Можем спокойно рефакторить и изменять код как угодно, т.к. у нас есть тесты, которые с уверенностью скажут, что мы где-то ошиблись
6. Повторяем все вышеуказанные шаги еще раз

Как подойти к этой задаче, используя BDD подход:

1. Процесс начинается с того что пользователь открывает форму
2. Нам нужно протестировать числа которые выдает форма
3. Нам нужно ввести 10–20 разных значений
4. Проверка в данном случае это нажатие на Submit кнопку и проверка значения
5. Тест пройдет если результат на форме соответствует “правильным” значениям

Далее мы это описываем с помощью специального синтаксиса (он зависит от инструмента, который используем, но суть одна). Например:

Функция: Расчет количества корма

Сценарий: При вводе валидных параметров отображается правильный ответ

Когда я нахожусь на странице с формой

И ввожу возраст 5 лет

И ввожу вес 5 кг

То мне отображается количество корма 500 г

Потом эти шаги реализуются в коде.

❓ Я фронтендер, зачем мне это надо

Умение тестировать свой код — очень жирный плюс для фронтендера, и вот почему:

• ты продумываешь детали еще до реализации, это помогает абстрагироваться от кода и уловить непонятные моменты в ТЗ на самом раннем этапе
• помогают наладить коммуникацию между разными членами команды: разработчиком, тестировщиком, менеджером и тд.
• раньше отлавливаются ошибки в коде, а чем раньше поймана бага, тем дешевле ее пофиксить
• меньше переходов туда-обратно таска от разработчика к тестировщику, значит, таски быстрее доедут до прода и меньше придется переключаться между тасками
• разгружаете своих ручных тестировщиков. Регрессионное тестирование — процесс очень трудоемкий. Если все покрыто автотестами, им достаточно просто описать тест-кейсы, код могут написать автоматизатор или разработчик
• можно смелее делать рефакторинг
• хорошие тесты — это еще и документация, и они помогают быстрее адаптироваться новым членам команды

PS В следующем посте расскажу об инструментах, которые мы используем для тестирования, и как у нас построен процесс.

Подписывайтесь на блоги: