В сегодняшней быстро развивающейся разработке программного обеспечения очень важна срочность выпуска высококачественных программных продуктов. Высококачественное программное обеспечение также должно быть свободным от всех возможных человеческих ошибок или других ошибок при его запуске. Есть ли эффективное средство реализации, которое может достичь таких максимальных программных результатов? Да, есть один. Это называется методом Test Driven Development (TDD).
Познакомьтесь: разработка через тестирование
TDD, или разработка через тестирование, — это метод разработки программного обеспечения, основанный на тестах, которые выполняются до разработки кода в ходе программных проектов. Идея сочетания рефакторинга процессов и итеративной разработки (TDD) в последнее время приобрела большую популярность.
TDD является одним из подходов к созданию высококачественного программного обеспечения, как упоминалось выше, знакомым с вышеуказанными целями? Да, TDD — это хорошая концепция разработки, применяемая к процессам Agile Scrum. TDD также поддерживает Agile Scrum Framework для создания надежного, поддерживаемого и масштабируемого кода.
3 правила TDD от дяди Боба
Роберт С. Мартин, или дядя Боб, записал правила TDD в главе 5 «Разработка через тестирование» своей книги «Чистый кодер» следующим образом:
1. Вам не разрешается писать какой-либо производственный код, кроме случаев, когда это необходимо для прохождения неудачного модульного теста.
2. Вам не разрешается писать больше модульного теста, чем достаточно для сбоя, а сбои компиляции — это сбои.
3. Вам не разрешается писать больше производственного кода, чем достаточно для прохождения одного ошибочного модульного теста.
Аргументы «за» и «против». Использование TDD
🧑🏻🦱: «Но разве TDD не сложно применить на практике?»
👱🏻: «Почему мы не можем просто начать писать код прямо сейчас?»
🧔🏻: «Ты работаешь дважды, если вы разрабатываете тест, пишете какой-то код, а затем проводите рефакторинг? Время потрачено впустую!»
Что ж, использование TDD породило множество контраргументов. Некоторые утверждают, что это сложно и не стоит. Хотя некоторые могут быть правы, говоря, что TDD требует гораздо больше работы, чем простое написание кода сразу.
Но осознавали ли вы, что TDD может быть более выгодным, чем его работа? Давайте углубимся в поиск его преимущества при его реализации!
- Инвестиции в ваш командный проект
Разработчики могут легко найти недостатки в процессе разработки, написав тесты перед написанием кода. Устранение проблем, в отличие от последующего исправления недостатков в кодовой базе, экономит много времени и денег. - Повышение качества кода
Написанный код может быть более модульным, тестируемым и простым в обслуживании при использовании TDD. Кроме того, это снижает технический долг и позволяет создавать код более высокого качества. - Более безопасный и упрощенный рефакторинг
TDD гарантирует, что тесты работают адекватно для обнаружения проблем. Таким образом, может быть создан менее рискованный код (и впоследствии рефакторинг), потому что он должен следовать только стандартному прохождению кода. - Экономит время
Хотя поначалу TDD может потребовать больше работы, в конечном итоге он экономит время, поскольку требуется меньше времени для отладки и поддержки кода.
Действительно, требуется много времени, чтобы привыкнуть к процессу TDD. Но многие инструменты и фреймворки могут помочь в работе с TDD, например, инструменты тестирования, фреймворки фиктивных объектов и фреймворки тестирования.
Как вы себя чувствовали?
Хотите глубже изучить концепцию TDD?
Поехали!🌊
Цикл TDD
1 — [КРАСНЫЙ] — Записать тест Fail
Перед написанием кода реализации необходимо написать тест. Все, что нужно сделать, это создать тесты для любого сценария, который может возникнуть в функционале программы. Вы знаете о принципе F.I.R.S.T? Это руководство, которое может сильно помочь при написании теста:
ПЕРВЫЙ принцип:
F – быстро. Тесты должны выполняться быстро и обеспечивать быструю обратную связь с разработчиком при внесении изменений в код. Медленные тесты усложняют разработку и затрудняют итерацию с медленным откликом обратной связи.
I — независимые. Тесты должны быть независимыми друг от друга, чтобы сбой в одной тестовой функции не влиял на другие тесты. Таким образом, возникающие проблемы изолируются и упрощают процесс отладки.
R — повторяемость. Тест должен иметь возможность запускаться повторно и давать один и тот же результат при каждом запуске или быть повторяемым. Этот принцип последователен и надежен в процессе тестирования.
S — самопроверка. Тест, конечно, должен сам по себе принимать правильное решение относительно прохождения или неудачи, когда он выполняется без вмешательства человека, что может увеличить вероятность человеческой ошибки.
T — своевременный, тест должен быть выполнен до реализации кода, чтобы сделать тест всеобъемлющим и охватить все аспекты кода.
Если тест не пройден, код тоже должен провалиться. Это написано в виде тега [RED] в сообщении коммита или означает, что код и тест по-прежнему терпят неудачу.
Для реализации в этом проекте PPL я сначала пишу тест с сообщением фиксации [RED], которое дает флаг, этот код не имеет реализации и только тест.
Помните!
Важно учитывать, что в тесте должны быть как положительные, так и отрицательные тестовые сценарии. Большая часть ошибок была обнаружена при отрицательном тестировании. Итак, что такое положительные тесты и отрицательные тесты в тестировании?
Положительный тест
Тестирование «счастливого» пути функциональности. Входные данные и путь должны соответствовать бизнес-требованиям и правильно выполнять условия, при этом не должно возникать странного поведения, вытекающего из функциональности, также имеет ожидаемые значения. Таким образом, положительный тест призван продемонстрировать, что система ведет себя правильно, когда она используется по назначению.
Все четко и гладко, как по маслу!
Вышеприведенный код является реализацией положительного теста, который описывает успешное извлечение lowongan с панели управления, поскольку роль администратора или суперадминистратора.
Отрицательный тест
Тестируя приложение и функциональность с необычными входными данными и создавая неверный путь для его проверки, с помощью этого отрицательного теста мы можем понять поведение приложения в отношении отрицательных записей. Этот тест также помогает выявить потенциальные проблемы и уязвимости, которые могут возникнуть при непредвиденных сценариях.
Реализация в этом проекте аналогична приведенному выше примеру кода для обработки крайних случаев, когда кто-то, у кого нет роли администратора (например, выпускник или компания), пытается получить доступ к этой панели инструментов, принудительно получая доступ к URL-адресу. Он будет перенаправлен на страницу входа.
2 — [ЗЕЛЕНЫЙ] — Время кодировать
На этом этапе разработчик может избежать дублирования кода, написав минимум кода, необходимый для прохождения теста. Исполняемая программа должна успешно пройти каждый тест. Таким образом, пройденный тест также вызывается в фиксации сообщения как [ЗЕЛЕНЫЙ].
Для реализации в этом проекте PPL я пишу код позже с сообщением о коммите [ЗЕЛЕНЫЙ], который дает флаг, который этот код уже реализовал, и тест должен пройти и успешно пройти, а также лучшие практики уже охватываются 100% покрытием.
Ура! покрытие кода пройдено означает, что покрытие составляет › 80% и тест работает хорошо. Это все из-за реализации TDD!
3 — [РЕФАКТОР] — Улучшить!
Теперь разработчик может вносить изменения в код, чтобы сделать его более удобным в сопровождении. Что изменилось, так это реализованный код, который должен пройти все тесты и не изменить поведение, которое уже есть. Этот процесс необходим для улучшения качества кода и снижения технического долга.
В реализации я хочу улучшить код, убрав запахи кода, которые обнаруживаются в пользовательском интерфейсе Sonarqube CS. Сообщение коммита содержит флаг [REFACTOR], что означает, что я изменяю свой код, чтобы улучшить его.
Вот, подведем итоги!
Разработка через тестирование (TDD) помогает нам гарантировать, что код разработан правильно. надежен и удобен в сопровождении за счет написания сначала тестов, а потом кода. Так что тест на написание будет пройден или не пройден в зависимости от ожидаемого поведения кода. TDD широко используется в современном программировании и стал важной практикой в процессе разработки. Хотя сначала требуется много усилий, чтобы написать код, он имеет много преимуществ, включая инвестиции в команду, чтобы иметь более надежный и удобный код. TDD обеспечивает систему безопасности, которая позволяет разработчикам разрабатывать и развертывать программное обеспечение быстрее и с большей уверенностью.
