Что такое разработка через тестирование? Требуется ли иметь первоначальный дизайн?

Question

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

Мое беспокойство по поводу TDD заключается в том, где он вписывается в наш SDLC. Предположим, я получил требование о создании системы обработки заказов. Теперь, не имея никакой модели и дизайна этой системы, как я могу начать писать тесты? Разве нам не нужно определять сущности и их атрибуты для продолжения? Если нет, то возможно ли разработать большую систему без какого-либо дизайна?

Answer 1

Существует два уровня разработки, основанной на TDD, ATDD или приемочном тестировании, и обычный TDD, основанный на модульных тестах.

Я полагаю, что на взаимосвязь между TDD и дизайном влияет несколько «гибкая» концепция, согласно которой исходный код является разработкой программного продукта. Многие люди подтверждают это, переводя TDD как Test Driven Design, а не как разработку. Это имеет большой смысл, поскольку TDD следует рассматривать как нечто большее, связанное с управлением проектом, чем с тестированием. Хороший побочный эффект - это приемочные и юнит-тесты в конце.

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

Для каждой пользовательской истории:

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

2. Теперь вы, вероятно, будете иметь смутное представление о том, какой тип программного обеспечения вам может понадобиться в отношении классов / поведения и т. Д.

3. Для каждого поведения:

4. Напишите ошибочный тест , который показывает, как для вызова кода вы хотели бы использовать класс .

5. Реализация поведения, обеспечивающего прохождение теста

6. Измените и тестовый, и фактический код, чтобы отразить хороший дизайн.

7. Переходите к следующему поведению.

8. Перейти к следующей истории пользователя.

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

Answer 2

Его следует назвать Test Driven Design , потому что это то, что он есть.

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

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

Answer 3

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

TDD работает хорошо итеративно:

1. Определите исходную проблемную область (может быть небольшим, эволюционный прототип)
2. Реализуй это
3. Расширение проблемной области (добавление функций, увеличение прототипа)
4. Рефакторинг и реализация его
5. Повторите шаг 3.

Конечно, вам необходимо заранее иметь смутное архитектурное видение (технологии, уровни, нефункциональные требования и т. Д.). Но функции, которые приносят дополнительную пользу вашему приложению, могут быть хорошо представлены в TDD.

См. Связанный вопрос TDD: хорошо для стартера?

Answer 4

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

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

Чтобы начать с TDD, включите ваши требования в тест. Для этого спросите: «Откуда мне знать, что это требование выполнено?» Если вы можете ответить на этот вопрос, напишите тест, который реализует ответ на этот вопрос. Это дает вам API, которому должен соответствовать ваш (подлежащий написанию) код. Это очень простой дизайн, но он всегда работает и б) гибок (потому что вы не можете протестировать негибкий код).

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

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

Это теория :-) На практике вы столкнетесь с парой проблем, но она работает довольно хорошо. Или, скорее, это работает лучше, чем что-либо еще, с чем я столкнулся.

Answer 5

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

1. Используя инфраструктуру модульного теста (я написал свой), напишите код, который вы хотите использовать, и тесты, чтобы убедиться, что возвращаемые значения и т. Д. Верны. Это гарантирует, что вы будете писать только тот код, который действительно собираетесь использовать. Я также добавлю еще несколько тестов для проверки крайних случаев.
2. Компиляция - вы получите ошибки компилятора !!!
3. Для каждой ошибки добавляйте объявления, пока не получите ошибок компилятора. Это гарантирует, что у вас есть минимальные объявления для вашего кода.
4. Ссылка - вы получите ошибки компоновщика !!!
5. Напишите достаточно кода реализации, чтобы удалить ошибки компоновщика.
6. Запустить - ваши юнит-тесты не пройдут. Напишите достаточно кода для успешного прохождения теста.

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

Мне нравится этот метод. Заставляет меня чувствовать тепло и нечеткость внутри.

Answer 6

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

Answer 7

Позвольте мне поделиться своим мнением:

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

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

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

Answer 8

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

Наиболее распространенной формой спецификаций, которые я видел, которые используются с TDD (и другими гибкими процессами), являются пользовательские истории - неформальный вид "варианта использования", который имеет тенденцию выражаться в несколько стереотипных английских предложениях. как «Как я могу» (форма пользовательских историй более или менее жесткая в зависимости от используемого стиля / процесса).

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

Answer 9

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