Хотя TDD требует упорного труда вначале, он определенно принесет пользу вашему будущему развитию.
«Сделать тест еще до того, как написать хоть одну строчку реального кода? Ты серьезно? », - сказал я в первый день занятий по веб-дизайну. Поначалу приводила в ярость попытка создать тест для воображаемой программы, которая, как предполагается, работает.
Однако, столкнувшись с сопутствующим ущербом из-за невыполнения TDD, я могу с уверенностью сказать, что разработка через тестирование имеет свои преимущества для непрерывного развития вашей программы. Почему? Потому что, если вы не пройдете какой-либо тест и не обнаружите ошибки в своей программе, будет сложно отследить, где вы ошиблись. Некоторые разработчики даже сказали: «Иногда более эффективно написать совершенно новую программу, чем искать ошибки в непроверенной программе».
Чтобы вы, ребята, не совершили ту же ошибку, что и я, я постараюсь немного рассказать о разработке через тестирование, преимуществах ее использования, лучших практиках TDD и примере реализации с Flutter.
Прежде всего, давайте посмотрим, как работает разработка через тестирование:
«Разработка через тестирование - это процесс разработки программного обеспечения, при котором программное обеспечение создается за очень короткие итерации с минимальным предварительным проектированием.» - Янцен Д. и Сайедян Х. (2005).
Разработка через тестирование начинается с размышлений о том, как протестировать требуемую функциональность. После написания автоматических тестовых примеров, которые обычно даже не компилируются, вы должны написать код реализации, чтобы пройти эти тестовые примеры. Работа находится под интеллектуальным контролем программиста; поскольку программист постоянно принимает небольшие решения по реализации и увеличивает функциональность с относительно постоянной скоростью.
Все тестовые примеры, существующие для всей программы, должны успешно пройти, прежде чем новый код будет считаться полностью реализованным. Следовательно, с некоторой степенью уверенности считается, что новый код не внесет ошибку или не замаскирует ошибку в текущей кодовой базе.
Еще одно эмпирическое правило в TDD заключается в том, что всякий раз, когда обнаруживается программный дефект, в набор тестов добавляются модульные тесты до исправления кода.
Важное правило TDD гласит: «Если вы не можете написать тест для того, что собираетесь кодировать, то вам не следует даже думать о кодировании».
Преимущества разработки через тестирование:
По словам Джорджа Б. и Уильямса Л. (2004), преимущества реализации разработки через тестирование заключаются в следующем:
- Понимание программы: по словам Т.А. Корби (1989), половина задачи программистов во время сопровождения программного обеспечения связана с пониманием кода. Подход TDD сделает программу более всеобъемлющей, поощряя программистов объяснять свой код с помощью тестовых примеров и самого кода, а не с помощью описательных слов. TDD также обеспечит актуальность тестовых примеров.
- Эффективность: исследователи TDD считают, что высокая степень детализации цикла «тест-код» дает программисту непрерывную обратную связь. С помощью TDD сбои выявляются быстро по мере добавления нового кода в систему; следовательно, источник проблемы легче определить
- Тестовые ресурсы: TDD обеспечивает возможность тестирования. Использование TDD побуждает программистов писать автоматически тестируемый код, например, функции / методы, возвращающие значение, которое можно проверить на соответствие ожидаемым результатам. Автоматизированные модульные тесты, написанные с помощью TDD, являются ценным активом для проекта.
- Уменьшение внедрения дефектов: Д. Гамлет, Дж. Мэйби (2001), утверждают, что отладка и обслуживание программного обеспечения часто воспринимаются как недорогие действия, при которых исправление дефекта рабочего кода для изменения его свойств, технические характеристики и дизайн не проверяются и не обновляются.
Лучшие практики разработки через тестирование:
Согласно руководству моего класса по разработке программного обеспечения, при использовании метода TDD необходимо соблюдать следующие правила:
- Сначала тестирование. Всегда проводите тестирование перед началом разработки программы. Помните принцип Red-Green-Refactor
- Критерии приемки. Все тесты относятся к критериям приемки, описанным в пользовательской истории.
- Онлайн-репозиторий: все разработки должны быть размещены в онлайн-хранилище.
- Веха фиксации [КРАСНЫЙ]: разработка должна быть начата с теста без реализации.
- Чистый тест: всегда помните ПЕРВЫЕ принципы! (Быстрый, Изолированный / Независимый, Повторяемый, Самопроверяющийся, Тщательный / Своевременный).
- Веха фиксации [ЗЕЛЕНЫЙ]: после успешного прохождения теста отправьте код в репозиторий.
- Покрытие кода: должно быть 100%, то есть весь ваш код должен быть тщательно протестирован, не оставляя ни одной непроверенной строки.
Реализация разработки через тестирование на Flutter:
Это пример простой программы, которая создает текстовое поле с помощью Flutter. Если вам интересно, как выглядят эти коды, вы можете прокрутить вниз и найти снимок экрана с результатами.
Сначала создайте файл main.dart
, если вы еще не настроили его! По крайней мере, так должно быть
Тогда, например, вы хотите сделать поле текстовой формы. Попробуйте сделать пустой класс textForm.dart
:
Нам не нужно сразу реализовывать класс. Вместо этого давайте проведем какой-нибудь тест, чтобы определить, какой результат мы хотим получить? Например, мы хотим знать, есть ли у нас один виджет поля текстовой формы и текст «Имя» над ним.
Мы могли бы реализовать это в файле с именем textFormTest.dart
. Не забудьте импортировать свой файл!
Вы можете запустить тест сейчас и получить результат, что ваш тест не прошел. Потрясающие!
Теперь давайте создадим реализацию для класса textForm.dart
!
Теперь, наконец, вы можете запустить тестовый файл в textFormTest.dart
файле, и теперь тест должен вернуться с успешным результатом!
Если вы скомпилируете main.dart file
, он должен выглядеть так:
Теперь, когда вы уже немного знаете о разработке через тестирование, давайте попробуем. Разработка через тестирование на ранней стадии разработки программного обеспечения, безусловно, принесет вам пользу в будущем.
Использованная литература:
- Джордж Б. и Уильямс Л. (2004). Структурированный эксперимент разработки через тестирование. Информационные и программные технологии, 46 (5), 337–342.
- Янзен, Д., и Сайедян, Х. (2005). Концепции разработки, основанной на тестировании, таксономия и направления на будущее. Компьютер, 38 (9), 43–50.
- Кауфманн Р. и Янцен Д. С. (2003). Последствия разработки через тестирование: тестовое исследование. В Companion 18-й ежегодной конференции ACM SIGPLAN по объектно-ориентированному программированию, системам, языкам и приложениям (стр. 298).
Подпишитесь на нас в Twitter 🐦 и Facebook 👥 и присоединитесь к нашей группе Facebook 💬 .
Чтобы присоединиться к нашему сообществу Slack 🗣️ и читать наши еженедельные темы о Фавнах 🗞️, нажмите здесь⬇