Хотя TDD требует упорного труда вначале, он определенно принесет пользу вашему будущему развитию.

«Сделать тест еще до того, как написать хоть одну строчку реального кода? Ты серьезно? », - сказал я в первый день занятий по веб-дизайну. Поначалу приводила в ярость попытка создать тест для воображаемой программы, которая, как предполагается, работает.

Однако, столкнувшись с сопутствующим ущербом из-за невыполнения TDD, я могу с уверенностью сказать, что разработка через тестирование имеет свои преимущества для непрерывного развития вашей программы. Почему? Потому что, если вы не пройдете какой-либо тест и не обнаружите ошибки в своей программе, будет сложно отследить, где вы ошиблись. Некоторые разработчики даже сказали: «Иногда более эффективно написать совершенно новую программу, чем искать ошибки в непроверенной программе».

Чтобы вы, ребята, не совершили ту же ошибку, что и я, я постараюсь немного рассказать о разработке через тестирование, преимуществах ее использования, лучших практиках TDD и примере реализации с Flutter.

Прежде всего, давайте посмотрим, как работает разработка через тестирование:

«Разработка через тестирование - это процесс разработки программного обеспечения, при котором программное обеспечение создается за очень короткие итерации с минимальным предварительным проектированием.» - Янцен Д. и Сайедян Х. (2005).

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

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

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

Важное правило TDD гласит: «Если вы не можете написать тест для того, что собираетесь кодировать, то вам не следует даже думать о кодировании».

Преимущества разработки через тестирование:

По словам Джорджа Б. и Уильямса Л. (2004), преимущества реализации разработки через тестирование заключаются в следующем:

  1. Понимание программы: по словам Т.А. Корби (1989), половина задачи программистов во время сопровождения программного обеспечения связана с пониманием кода. Подход TDD сделает программу более всеобъемлющей, поощряя программистов объяснять свой код с помощью тестовых примеров и самого кода, а не с помощью описательных слов. TDD также обеспечит актуальность тестовых примеров.
  2. Эффективность: исследователи TDD считают, что высокая степень детализации цикла «тест-код» дает программисту непрерывную обратную связь. С помощью TDD сбои выявляются быстро по мере добавления нового кода в систему; следовательно, источник проблемы легче определить
  3. Тестовые ресурсы: TDD обеспечивает возможность тестирования. Использование TDD побуждает программистов писать автоматически тестируемый код, например, функции / методы, возвращающие значение, которое можно проверить на соответствие ожидаемым результатам. Автоматизированные модульные тесты, написанные с помощью TDD, являются ценным активом для проекта.
  4. Уменьшение внедрения дефектов: Д. Гамлет, Дж. Мэйби (2001), утверждают, что отладка и обслуживание программного обеспечения часто воспринимаются как недорогие действия, при которых исправление дефекта рабочего кода для изменения его свойств, технические характеристики и дизайн не проверяются и не обновляются.

Лучшие практики разработки через тестирование:

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

  1. Сначала тестирование. Всегда проводите тестирование перед началом разработки программы. Помните принцип Red-Green-Refactor
  2. Критерии приемки. Все тесты относятся к критериям приемки, описанным в пользовательской истории.
  3. Онлайн-репозиторий: все разработки должны быть размещены в онлайн-хранилище.
  4. Веха фиксации [КРАСНЫЙ]: разработка должна быть начата с теста без реализации.
  5. Чистый тест: всегда помните ПЕРВЫЕ принципы! (Быстрый, Изолированный / Независимый, Повторяемый, Самопроверяющийся, Тщательный / Своевременный).
  6. Веха фиксации [ЗЕЛЕНЫЙ]: после успешного прохождения теста отправьте код в репозиторий.
  7. Покрытие кода: должно быть 100%, то есть весь ваш код должен быть тщательно протестирован, не оставляя ни одной непроверенной строки.

Реализация разработки через тестирование на Flutter:

Это пример простой программы, которая создает текстовое поле с помощью Flutter. Если вам интересно, как выглядят эти коды, вы можете прокрутить вниз и найти снимок экрана с результатами.

Сначала создайте файл main.dart, если вы еще не настроили его! По крайней мере, так должно быть

Тогда, например, вы хотите сделать поле текстовой формы. Попробуйте сделать пустой класс textForm.dart:

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

Мы могли бы реализовать это в файле с именем textFormTest.dart. Не забудьте импортировать свой файл!

Вы можете запустить тест сейчас и получить результат, что ваш тест не прошел. Потрясающие!

Теперь давайте создадим реализацию для класса textForm.dart!

Теперь, наконец, вы можете запустить тестовый файл в textFormTest.dart файле, и теперь тест должен вернуться с успешным результатом!

Если вы скомпилируете main.dart file, он должен выглядеть так:

Теперь, когда вы уже немного знаете о разработке через тестирование, давайте попробуем. Разработка через тестирование на ранней стадии разработки программного обеспечения, безусловно, принесет вам пользу в будущем.

Использованная литература:

  1. Джордж Б. и Уильямс Л. (2004). Структурированный эксперимент разработки через тестирование. Информационные и программные технологии, 46 (5), 337–342.
  2. Янзен, Д., и Сайедян, Х. (2005). Концепции разработки, основанной на тестировании, таксономия и направления на будущее. Компьютер, 38 (9), 43–50.
  3. Кауфманн Р. и Янцен Д. С. (2003). Последствия разработки через тестирование: тестовое исследование. В Companion 18-й ежегодной конференции ACM SIGPLAN по объектно-ориентированному программированию, системам, языкам и приложениям (стр. 298).

Подпишитесь на нас в Twitter 🐦 и Facebook 👥 и присоединитесь к нашей группе Facebook 💬 .

Чтобы присоединиться к нашему сообществу Slack 🗣️ и читать наши еженедельные темы о Фавнах 🗞️, нажмите здесь⬇

Если этот пост был полезен, пожалуйста, нажмите несколько раз кнопку хлопка 👏 ниже, чтобы выразить поддержку автору! ⬇