TDD — разработка через тестирование
TDD, test-driven development или процесс разработки через тестирование — это методология разработки программного обеспечения, которая основывается на повторении коротких циклов разработки:
- Пишется тест, покрывающий желаемое изменение.
- Пишется программный код, который реализует желаемое поведение системы и позволяет пройти написанный тест.
- проводится рефакторинг написанного кода с постоянной проверкой прохождения всех тестов.
Тестирование ПО — это процедура, которая позволяет подтвердить или опровергнуть работоспособность кода и корректность его работы. При тестировании приложению передаются входные данные и запрашивается выполнение некой команды, после чего производится проверка полученных результатов на соответствие эталону, если результат соответствует ожидаемому — тест считается пройденным.
Процедура тестирования может быть автоматизирована, в этом случае проверка работоспособности и правильности работы приложения в сравнении с ручным тестированием осуществляется гораздо быстрее, полноценнее и фактически чаще.
Методика разработки через тестирование заключается в организации автоматического тестирования разрабатываемых приложений путем написания модульных, интеграционных и функциональных тестов, определяющих требования к коду непосредственно перед написанием этого самого кода.
Сначала пишется тест, который проверяет корректность работы еще ненаписанного программного кода. Этот тест, разумеется, не проходит. После этого разработчик пишет код, который выполняет действия, требуемые для прохождения теста. После того, как тест успешно пройден, по необходимости осуществляется рефакторинг (доработка и переработка) написанного кода, причём в этом случае рефакторинг осуществляется уже под контролем прохождения тестов, что проще и надёжнее.
Цикл разработки по TDD
- Добавить тест для новой (еще не реализованной) функциональности или для воспроизведения существующего бага
- Запустить все тесты и убедиться, что новый тест не проходит
- Написать код, который обеспечит прохождение теста:
- Запустить тесты и убедиться, что они все прошли успешно: прохождение нового теста подтверждает реализацию нового функционала или исправление существующей ошибки, а прохождение остальных позволяет удостовериться, что ранее реализованный функционал работает по‑прежнему корректно.
- Заняться рефакторингом и оптимизацией — улучшение сопровождаемости и быстродействия целесообразно осуществлять уже после того, как получилось добиться проверяемой работоспособности
- Перезапустить тесты и убедиться, что они все ещё проходят успешно
- Повторить цикл
Эта методология позволяет добиться создания пригодного для автоматического тестирования приложения и очень хорошего покрытия кода тестами. ТЗ переводится на язык автоматических тестов, то есть всё, что программа должна делать, проверяется. Также TDD часто упрощает программную реализацию: так как исключается избыточность — если компонент проходит тест, то он считается готовым. Если же существующие тесты проходят, но работает компонент не так, как ожидается, то это значит, что тесты пока не отражают всех требований, а это повод добавить новые тесты.
Архитектура программных продуктов, разрабатываемых таким образом, обычно лучше (в приложениях, которые пригодны для автоматического тестирования, обычно очень хорошо распределяется ответственность между компонентами, а выполняемые сложные процедуры декомпозированы на множество простых). Стабильность работы приложения, разработанного через тестирование, также выше за счёт того, что все основные функциональные возможноси программы покрыты тестами и их работоспособность регулярно проверяется. Сопровождаемость проектов, где тестируется всё или практически всё, очень высока — разработчики могут не бояться вносить изменения в код, если что‑то пойдёт не так, то об этом ещё до релиза сообщат результаты автоматического тестирования.
Тематические статьи
Стандарты кодирования — залог хорошей сопровождаемости проекта
Любая командная разработка может быть эффективной только в том случае, если участники команды имеют общее видение.
Если над проектом работает команда, а не один‑два разработчика, то обязательно должен быть стандарт оформления кода — набор правил и соглашений, которые описывают базовые принципы оформления программного кода, используемого совместно группой разработчиков.
SOLID — принципы объектно‑ориентированного программирования
SOLID это аббревиатура пяти основных принципов проектирования в объектно‑ориентированном программировании, предложенных Робертом Мартином:
- Single responsibility — принцип единственной ответственности
- Open-closed — принцип открытости / закрытости
- Liskov substitution — принцип подстановки Барбары Лисков
- Interface segregation — принцип разделения интерфейса
- Dependency inversion — принцип инверсии зависимостей
Принцип программирования YAGNI — «Вам это не понадобится»
Принцип заключается в том, что возможности, которые не описаны в требованиях к системе, просто не должны реализовываться.
В результате разработка ненужных функций не сжигает бюджет проекта, а разработчики не тратят оплачиваемое время на реализацию и дальнейшее сопровождение в реальности ненужного функционала. Избыточный функционал сжигает больше всего ресурсов именно на сопровождении: больше написанного кода — труднее сопровождать и выше вероятность появления «багов». И тут очень уместна поговорка: «лучший код — это ненаписанный код».
Принцип программирования KISS — делайте вещи проще
KISS — это принцип проектирования и программирования, при котором простота системы декларируется в качестве основной цели или ценности.
Большая часть программных систем необосновано перегружена практически ненужными функциями, что ухудшает удобство их использование конечными пользователями, а также усложняет их поддержку и развитие разработчиками. Следование принципу KISS позволяет разрабатывать решения, которые не обладают этими недостатками: они просты в использовании и в сопровождении.
Принцип программирования DRY — don’t repeat yourself / не повторяйте себя
Следование принципу DRY позволяет добиться высокой сопровождаемости программного продукта: внесение изменений и тестирование значительно упрощаются.
Если код не дублируется, то для изменения логики достаточно внесения исправлений всего в одном месте. Также значительно проще тестировать одну (пусть и более сложную) функцию, а не набор из десятков однотипных. При следовании DRY упрощается и повторное использование функций, вынесенных из сложных алгоритмов, что позволяет сократить время разработки и тестирования новой функциональности.
Флаги функций (Feature Flags)
Флаги функций позволяют отделить развертывание функций от развертывания кода, обеспечивают возможности для A/B-тестирования и предоставляют механизм быстрого отключения проблемных функций
Модель ветвления Trunk Based Development (TBD)
Trunk Based Development (TBD) или транковая разработка — модель ветвления системы управления версиями, при которой все разработчики работают в одной ветке. Эта модель имеет значительные преимущества с точки зрения совместной работы, качества кода и скорости доставки изменений.
Процессы, необходимые для информационной безопасности
Информационная безопасность важна практически для любого бизнеса, так как деятельность почти всех компаний достаточно существенно зависит от информационных технологий.
Взломы, утечки данных и неработоспособность ключевых систем приводит как к финансовых потерям, так и к репутационным издержкам. Чтобы снизить риски в сфере ИБ стоит внедрять базовые процессы ИБ в разработку, тестирование и системное администрирование.
MVC — модель‑представление-контроллер
MVC — это паттерн проектирования приложений, который разделяет на три отдельных компонента модель данных приложения, пользовательский интерфейс и слой взаимодействия с пользователем.
В парадигме MVC контроллер определяет способы взаимодействия пользователя с приложением, модель — за слой хранения данных и бизнес‑логику, а представление — за пользовательский интерфейс / формат выходных данных. Модификация каждого из этих компонентов либо оказывает минимальное воздействие на остальные, либо не оказывает его вовсе. Это облегчает понимание логики работы системы и упрощает внесение изменений в кодовую базу.