- Оригинальный адрес:Outside-In development with Double Loop TDD
- Оригинальный автор:Emily Bache
- Перевод с:Программа перевода самородков
- Постоянная ссылка на эту статью:GitHub.com/rare earth/gold-no…
- Переводчик:Yong Li
- Корректор:Liao Malin
Внешняя разработка с двойным циклом TDD
в моем предыдущем постестатьяВ статье я начал обсуждать Лондонскую школу разработки через тестирование (TDD) и две особенности, которые, как мне кажется, отличают ее от традиционной TDD. Первый — это внешняя разработка с использованием двухконтурного TDD, о котором я подробно расскажу в этом посте. Второй момент — это объектно-ориентированный дизайн «говори, не спрашивай», о котором я расскажу вследующий постОбсудите снова.
Двойное кольцо TDD
Когда вы выполняете TDD с двойным кольцом, время, которое вы тратите на внутреннее кольцо, измеряется в минутах, а время, которое вы тратите на внешнее кольцо, измеряется в часах или днях. Тесты внешнего цикла пишутся с точки зрения внешнего пользователя системы, обычно охватывают грубую функциональность и развертываются в реальной (или, по крайней мере, близкой к реальной) среде. существуетмоя книгаЯ называю эти типы тестов «Направляющими тестами», а Фримен и Прайс называют их «Приемочными тестами». Эти тесты должны терпеть неудачу, если ожидания клиентов не оправдываются — другими словами, они обеспечивают хорошую защиту от возврата. Они также документируют, как должна вести себя система. (См. также мою статью "Принципы Agile Automation Test Design»)
Я не думаю, что TDD с двойным циклом уникален для TDD в лондонском стиле, и я уверен, что традиционные разработчики TDD тоже примут его. Эта идея существовала еще в первой книге Кента Бека по экстремальному программированию. Но я думаю, что уникальность «Лондонского пирога» заключается в дизайне «снаружи-внутрь», дополненном использованием макетов.
Разработан наружу
Если вы используете TDD с двойным циклом, вы обычно начинаете с написания управляемого теста, чтобы продемонстрировать, как пользователь взаимодействует с вашей системой. Этот тест поможет вам определить, какая функция или класс находится на самом верхнем уровне и какая вызывается первой в качестве точки входа для требуемой функциональности. Часто это компонент графического интерфейса, ссылка на веб-странице или флаг командной строки.
Для TDD в лондонском стиле, когда вы начнете разрабатывать классы или методы TDD внутреннего цикла, которые вызываются компонентом GUI, веб-ссылкой или флагом командной строки, вы быстро поймете, что новый код не может реализовать всю функцию. самостоятельно, но вам нужны другие совместные классы, чтобы завершить это вместе.
Пользователь наблюдает за системой и ожидает определенной функциональности. Это означает, что границы системы требуют нового класса. Этот класс, в свою очередь, требует дополнительных взаимодействующих классов, которых еще не существует.
Эти сотрудничающие классы еще не существуют или, по крайней мере, не предоставляют всех необходимых вам функций. Вместо того, чтобы приостанавливать TDD на этом этапе и сразу разрабатывать эти новые классы, вы можете фактически заменить их макетами в своих тестах. Часто легко заменить имитации и поэкспериментировать с кодом, пока вы не разработаете интерфейс и протокол, отвечающие вашим потребностям. Таким образом, когда вы разрабатываете тестовые примеры, вы также разрабатываете производственный код.
Вы можете заменить сотрудничающие объекты макетами, чтобы создавать интерфейсы и протоколы между ними.
Когда вы удовлетворены своим дизайном и тесты пройдены, вы можете перейти на следующий уровень, чтобы фактически реализовать совместный класс. Конечно, если классу в дальнейшем нужны другие соавторы, вы можете заменить их макетами для дальнейшего проектирования этих интерфейсов. Этот подход может продолжаться на всем протяжении проектирования системы через различные уровни архитектуры и абстракции.
Вы завершили класс для границы системы, и теперь вы можете разработать один из его взаимодействующих классов и заменить взаимодействующие классы, которые нужны классу, макетами.
Этот способ работы позволяет разбить проблему на управляемые части, и каждый раз, когда вы начинаете новую часть, текущая часть может быть указана и полностью протестирована. Вы можете начать с того, что сосредоточитесь на потребностях пользователей, а затем строить извне, отслеживая весь процесс взаимодействия с пользователем по частям в системе до тех пор, пока не пройдет контрольный тест. Обычно в управляемых тестах вы не заменяете части системы макетами, чтобы в конечном итоге, когда управляемые тесты прошли, вы могли быть уверены, что не забыли реализовать ни один из взаимодействующих классов.
Снаружи в традиционном TDD
Подход «снаружи внутрь» также возможен в традиционном подходе TDD, но в подходе, который практически не требует насмешек. Существует несколько различных стратегий для решения проблемы «коллаборативного класса еще не существует». Один из них — начать проектирование с вырожденного варианта использования, когда с точки зрения пользователя почти ничего не происходит. Это особый случай, когда вывод намного проще, чем фактический вариант использования или счастливый путь. Таким образом, вы можете использовать только самую простую пустую реализацию или возвращаемое значение false для построения структуры и методов класса, которые требуются для этой упрощенной версии функционального требования. Когда у вас есть структура, вы можете конкретизировать ее (возможно, изнутри наружу).
Другая стратегия «снаружи внутрь» в традиционном TDD заключается в том, чтобы сначала написать тесты снаружи внутрь, а когда вы обнаружите, что не можете пройти тест до того, как будет реализован сотрудничающий класс, закомментируйте этот тест и перейдите к разделу «Реализовать требуемый». совместные классы. В конце концов вы обнаружите, что можете полностью реализовать класс только с существующими соавторами, а затем продвигаться вверх.
Снаружи-внутрь иногда может вообще не работать в традиционных методах TDD. Вы начнете с класса в System Center и выберете часть, которую можно полностью реализовать и протестировать только с существующими соавторами. Обычно это класс в центре модели предметной области приложения. Когда это будет сделано, вы продолжите развивать систему от центра к краю, добавляя новые классы один за другим. Поскольку вы используете только существующие классы, вам почти никогда не нужно использовать макеты. В конце концов вы также обнаружите, что выполнили все функции, а также прошли управляемый тест.
Преимущества и недостатки
Я думаю, что существуют значительные преимущества для внешнего подхода. Это поможет вам сосредоточиться на том, что действительно хочет ваши пользователи, так что вы можете построить что-то действительно полезное, не тратя времени для полировки того, что ваши пользователи не нужны. Я думаю, что внешний подход требует навыков и обучения, как для традиционного TDD, так и для Лондонского стиля TDD. Обучение того, как сломать функциональные возможности на инкрементные части, которые вы можете разрабатывать, и дизайн пошаговый на шаг непросто. Но если вы работаете из центра от центра, есть риск, который вы построите что-то, что ваши пользователи не нуждаются, или когда вы попадаете на внешний слой, вы в конечном итоге вы найдете, что система не работает, и вы должны рефакторировать.
Однако, предполагая, что вы уже работаете снаружи внутрь, я все еще думаю, что это зависит от того, пишете ли вы фальшивую реализацию в реальном производственном коде или просто макет. Если вы пишете производственный код, вам нужно постепенно заменить их реальными функциями. И если вы поместите поддельные функции в моки, они могут жить в тестовом коде вечно, даже если настоящие функции реализованы, они все еще там. Это полезно для документации программы и позволяет вашим тестам продолжать быстро выполняться.
Сказав это, есть некоторые споры о ремонтопригодности после использования большого количества макетов в тестах. При изменении дизайна обновление всех макетов в дополнение к производственному коду может оказаться слишком дорогим. Как только реальная реализация будет завершена, возможно, следует удалить тест внутреннего цикла? В конце концов, все управляемые тесты уже обеспечивают всю необходимую вам защиту от возврата, так что тесты, которые полезны только для вашего исходного проекта, не стоят того, чтобы их оставлять? Я не думаю, что это безупречный поступок. Из моих обсуждений с некоторыми сторонниками лондонцев, даже если они удалят некоторые тесты, они не удалят все тесты, использующие моки.
Я также все еще пытаюсь разобраться в этих спорах и пытаюсь выяснить, где лондонский пирог TDD может принести наибольшую пользу. Надеюсь, я обрисовал различия между различными подходами к развитию снаружи-внутри. В следующей статье я расскажу, как популяризируется TDD «Лондонский пирог».Объектно-ориентированный дизайн «Говори, не спрашивай»из.
Программа перевода самородковэто сообщество, которое переводит высококачественные технические статьи из Интернета сНаггетсДелитесь статьями на английском языке на . Охват контентаAndroid,iOS,внешний интерфейс,задняя часть,блокчейн,продукт,дизайн,искусственный интеллектЕсли вы хотите видеть более качественные переводы, пожалуйста, продолжайте обращать вниманиеПрограмма перевода самородков,официальный Вейбо,Знай колонку.