Разработка через тестирование - это путь. Но как это сделать?

Question

Некоторые разработчики проектируют свои приложения, используя Test Driven Development (TDD), но я хотел бы знать, на каком этапе мне следует включать TDD в мои проекты? Должен ли я сначала спроектировать свои классы, провести какие-то юнит-тесты и определить, какие методы нужны, или сначала спроектировать методы, а затем провести несколько юнит-тестов?

Как лучше всего это сделать?

Answer 1

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

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

Answer 2

Цель теста в том, что тесты определяют как дизайн, так и реализацию.

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

Обычно, если что-то легко проверить, его будет легко использовать.

Answer 3

Мантра для тестового дизайна:

• создать тест.
• тест компиляции (и проверка того, что он не прошел)
• написать интерфейс
• тест компиляции (он должен скомпилироваться сейчас)
• запустить тест (сейчас он не пройдёт)
• написать код
• Скомпилируйте / запустите тест (он должен сделать оба сейчас)

Повторите для каждого элемента.

Answer 4

Начните с малого

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

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

в) Затем вы должны решить, будете ли вы разрабатывать свое приложение для облегчения модульного тестирования. Например,

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

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

Answer 5

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

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

Не поймите меня неправильно. Я все за хорошо разработанное программное обеспечение, и в определенный момент важно, чтобы организованный хаос трансформировался в хорошо понятный дизайн. В этот момент структура классов и UML-диаграммы начинают укрепляться. В этом и заключается смысл TDD для меня. Каждый класс должен быть в состоянии быть изолированным. Если дизайн хорош с правильной степенью развязки, то этого легко добиться, обычно разбрызгивая ложные объекты по всему месту. Если дизайн плохой, тестирование становится настоящим кошмаром и, следовательно, игнорируется.

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

Answer 6

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

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

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

Answer 7

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

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

Answer 8

TDD гарантирует, что разработчики придают одинаковое значение тестовым сценариям по сравнению с их бизнес-логикой. Я следовал за этим в своем проекте, и я мог видеть преимущества: так как я начал с написания своих тестовых примеров в первую очередь, я обеспечил, чтобы мои тестовые случаи обрабатывали все возможные покрытия бизнес-логики, тем самым выявляя / уменьшая количество ошибок. Иногда это не практично, поскольку для написания этих тестов требуется достаточно времени. Суть в том, что вам нужно действительно хорошо выполнить модульное тестирование своего кода. Так что либо вы начинаете с реализации, а затем гарантируете, что для всех сценариев имеется достаточно тестовых случаев (большинство людей этого не делают, поэтому такая практика уже возникла). пробный прогон, а затем написать свою реализацию. Говорят, что ваша реализация завершена только тогда, когда все ваши тесты успешно пройдены.

Answer 9

Пожалуйста, посмотрите на

http://en.wikipedia.org/wiki/Test-driven_development

Они поставили задачи высокого уровня