Резюме разработки через тестирование (TDD) — принципы

Я инженер-разработчик программного обеспечения, которому нравится создавать высококачественный код и эффективно работать, поэтому я изучаю такие принципы, как SOLID и Simple Design, читаю отличный открытый исходный код, читаю книги по теме, изучаю методы разработки ПО и практику реальных проектов, но в На пути к созданию высококачественного кода я всегда чувствую, что мои текущие знания не могут помочь мне преобразовать его в структуру мышления. Прочитал случайно в начале 2018Учебное пособие по TDD (Разработка через тестирование)Эта статья сразу в восторге!

В контакте с TDD уже почти год.В этот период я практиковался в проекте какое-то время, потому что прочитал несколько материалов.Результаты неплохие.Я думаю, что уже понял практику TDD и размышления, лежащие в его основе. Читая соответствующие книги и обсуждая некоторые TDD, я продолжал разоблачать свое невежество, и я оказался на невежественном пике кривой «эффекта Дака». Большая часть знаний, которые я считал правильными, были неточными или даже неправильно. Но мне очень нравится этот процесс, очень интересно постоянно проверять свои знания в процессе обучения, что заставляет меня осознавать себя и постоянно раздвигать границы своего познания.

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

Сфера

TDD (разработка, управляемая тестированием) может иметь разное понимание в разных кругах и в разных ролях. во избежание двусмысленности,Статья посвящена TDD и конкретно относится к UTDD (разработка, управляемая модульным тестированием), что означает «разработка, основанная на модульном тестировании»..

Что такое ТДД

В прошлом очень однобоко считалось, что TDD = принцип XP «сначала тестирование» + рефакторинг, полагая, что TDD только способствует написанию кода посредством модульного тестирования, а затем оптимизирует внутреннюю структуру программы посредством рефакторинга. Легко понять, что вам нужно сначала написать модульные тесты, чтобы управлять высококачественным кодом, Только когда я прочитал книгу Кента Бека «Разработка через тестирование» и попрактиковался в мышлении, я, наконец, увидел лицо TDD. скрыто под айсбергом:

Кент Бек: «Разработка через тестирование — это не метод тестирования. Это метод анализа, метод проектирования и метод организации всей деятельности по разработке».

аналитические навыки:Это находит свое отражение в анализе проблемной области.Когда проблема не была разложена на практические задачи, пригодятся методы анализа, такие как анализ требований, разделение задач и планирование задач и т. д. Книга «Требования на примере» может дать немного помощи.

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

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

Цель TDD

Как пишет Кент Бек в своей книге «Разработка через тестирование»: «Код лаконичный и удобныйЭто краткое утверждение — именно то, что нужно TDD».

Чтобы обеспечить «краткий и удобный код», можно использовать метод «разделяй и властвуй», и сначала достигается цель «удобный», а затем преследуется цель «простой».

Доступный:Убедитесь, что ваш код проходит автоматические тесты.

Код лаконичен:На разных этапах люди по-разному понимают простоту, но следуют схожим принципам, таким как принцип SOLID OOD, принцип Kent BeckSimple Designпринципы и др.

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

Правила ТДД

В процессе TDD необходимо соблюдать два простых правила:

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

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

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

Слоган TDD

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

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

Если предположить, что такой подход к разработке возможен, какова моя реальная мотивация для принятия TDD?

Мотивация для принятия TDD

Контролируйте тревогу во время программирования.

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

Устранение разрыва между обратной связью и принятием решений в процессе программирования.

Если я планирую неделю и определяю его количество в практических задачах и записываю их в список дел, а затем использую кодирование через тестирование, помещаю выполненные задачи~~Задача~~Вычеркните это так, и тогда мои рабочие цели станут очень ясными, потому что у меня есть четкое расписание, четкие задачи, четкие трудности и я могу сознательно вносить соответствующие коррективы в непрерывной тонкой обратной связи, например, добавлять новые задачи, удалять лишние тесты, еще более интересно, что я приблизительно знаю, когда закончу. Руководители проектов могут более точно понимать ход разработки программного обеспечения.

Общий процесс TDD

Подумайте, что я собираюсь сделать, подумайте, как это протестировать, и напишите небольшой тест. Подумайте о необходимых классах, интерфейсах, входах и выходах.
Напишите достаточно кода, чтобы сделать тест провальным (явный провал всей модели пухового одеяла).
Haoshi просто напишите, что тест кода пройден (письменное тестирование гарантии также должно пройти раньше).
Запускайте и наблюдайте за всеми тестами. Если не пройдет, исправьте сейчас и ошибка просто ляжет в только что добавленный код.
Если есть какая-либо повторяющаяся логика или необъяснимый код, рефакторинг может устранить дублирование и улучшить выразительность (меньше связанности, больше связности).
Запустите тесты еще раз, чтобы убедиться, что рефакторинг не приводит к появлению новых ошибок. Если он не проходит, вполне вероятно, что при рефакторинге были допущены какие-то ошибки, и их необходимо немедленно исправить и запустить повторно, пока все тесты не пройдут.
Повторяйте описанные выше шаги до тех пор, пока не будут найдены тесты, приводящие к написанию нового кода.

Три стратегии, чтобы сделать тестовую программу работоспособной:

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

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

Трудности с TDD

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

TDD вопросы

Говорят бежать мелкими шагами, но насколько мал конкретный темп?

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

Что нужно протестировать? Что не требует тестирования?

Это зависит от вашего опыта и уровня уверенности в своем коде, за исключением тех, кто может чувствовать себя очень уверенно в своем коде без написания тестов. Если есть какой-то код, который, по вашему мнению, вы можете запускать и рефакторить с большой уверенностью, даже если он вам не нужен, как большинство set get , и вы не чувствуете себя комфортно, удаляя его, вам нужно подумать о добавлении теста.

Почему вам нужно следовать порядку неработоспособный/работоспособный/рефакторинг, и нельзя ли использовать любой другой порядок?

Кент Бек, автор «Test Driven Development», также затрудняется доказать эту проблему, потому что ни один специальный человек на самом деле не проводил эту статистику, поэтому он сказал, что не отрицает, что могут быть более удачные последовательные проекты.

Зачем писать только «доступный» код каждый раз на этапе выполнения?

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

Является ли TDD серебряной пулей?

TDD — это не панацея.

модульный тест

В отличие от АТДД,UTDD в основном для разработчиков,такUTDD здесь в первую очередь касается атрибутов качества в программном обеспечении., если внешнее качество программного обеспечения отражается в таких показателях, как «количество дефектов» и «коэффициент дефектности», тоВнутренние атрибуты качества программного обеспечения отражаются в «тестируемости», «читабельности» и «расширяемости» кода и т. д., это цель почти каждого инженера-разработчика программного обеспечения. Как один из продуктов TDD, «модульное тестирование» обычно используется в качестве «основы» обеспечения качества программного обеспечения для контроля внутренних атрибутов качества программного обеспечения.

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

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

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

Из описания Википедии видно, что юнит-тесты имеют следующие характеристики

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

Вот простой анализ модульного тестирования с моей личной точки зрения, но понимание «модульного тестирования» или того, где оно находится, все еще недостаточно ясно, поэтому далее я использую модель «тестовой пирамиды», чтобы помочь мне подняться выше. - уровень понимания "модульного тестирования".

тестовая пирамида

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

Суммировать

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

следовать за

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

Ссылки на литературу

тригонометрия
Мысли о реализации TDD - Чжан И
Записи об обучении TDD (разработка через тестирование)

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