Как начать модульное тестирование или TDD?

Question

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

Будет ли предпочтительный способ писать модульные тесты перед методами, описанными в методологии TDD?

Есть ли какая-либо другая методология или способ для модульного тестирования?

Answer 1

Тест первого/тест после:

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

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

I.e. если вы пишете плохой тест раньше, вы можете получить зеленый свет, когда вы ожидаете красного (так что вы знаете, что тест плох). Если после этого вы напишите плохой тест, вы получите зеленый свет, когда вы ожидаете зеленого цвета (не подозревая о плохом тесте).

Книги

Прагматический модульного тестирования книга стоит посмотреть, как Рой Osherove «Искусство модульного тестирования». Прагматическая книга более узко ориентирована на различные типы тестовых входов, которые вы можете попытаться найти ошибки, тогда как TAOUT охватывает более широкое распространение таких тем, как двойные тесты, стратегии, ремонтопригодность и т. Д. Либо книга хороша; это зависит от того, что вы хотите от него.

Также есть link to a talk Roy Osherove did on unit testing. Это стоит посмотреть (так же, как и некоторые из видеозаписей, которые он записал, так как он указывает на различные проблемы и dos/don'ts вместе с причинами).

Как начать

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

Всегда спрашивайте себя: «Что я хочу попробовать и докажу с помощью этого теста?» перед тем, как вы его напишете, дайте ему достойное имя (обычно включающий вызываемый метод, сценарий и ожидаемый результат, например, в стеке: «Pop WhenStackIsEmpty ThrowsException»).

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

Answer 2

У Стива Сандерса есть отличная запись о лучших методах TDD.

http://feeds.codeville.net/~r/SteveCodeville/~3/DWmOM3O0M2s/

Кроме того, есть большой набор обучающих программ для этого в MVC проект ASP.net, который обсуждает много TDD принципы (если вы не против обучения ASP.net MVC по пути) http://www.asp.net/learn/mvc-videos/ Look для серии «Storefront» в нижней части страницы.

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

В общем, попробуйте написать тест, чтобы проверить что-то you'r пытается в архив, а затем реализовать код сделай так, чтоб это работало.

Паттерн известен как Красный - Зеленый - Рефактор. Также сделайте все возможное, чтобы минимизировать зависимости, чтобы ваши тесты могли сосредоточиться на одном компоненте.

Лично я использую Visual Studio Unit Tests. Я не хардкорный разработчик TDD, но то, что я хотел бы сделать это:

1. Создайте новый проект и определить несколько основных классов, основанных на конструкции системы (таким образом я могу по крайней мере, получить некоторые intellisense)
2. создать проект единичных тестов и начать писать модульные тесты, чтобы удовлетворить функциональность, которую я пытаюсь реализовать.
3. Сделать их неудачу
4. Заставьте их пройти (реализации)
5. Refactor
6. Repeat, попробуйте сделать тест более строгим или создавать больше тестов, пока я не чувствую его твердый.

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

Answer 3

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

Если вы заинтересованы в работе с TDD, то дядя Боб - хороший источник. Частичный this.

Подробнее о модульном тестировании

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

Испытания не требуют настройки.

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

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

Answer 4

Прочитано Pragmatic Unit Testing in C# with NUnit. Он имеет исчерпывающую информацию о начале написания тестов и структурировании кода, чтобы сделать его более удобным для тестирования.

Answer 5

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

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

Answer 6

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

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

Как только вам будет удобно записывать модульные тесты, вы можете попробовать сделать TDD.

Answer 7

В C# и с визуальной студии я нахожу следующие процедуры очень полезны:

1. Подумайте! Сделайте небольшой авангардный дизайн. Вы должны иметь четкое представление о том, какие классы вам нужны и как объекты должны относиться друг к другу. Сосредоточьтесь только на одном классе/объекте (класс/объект, который вы хотите реализовать) и одну связь. В противном случае вы получите слишком тяжелый дизайн. Я часто заканчиваю несколькими эскизами (всего несколько коробок и стрелок) на запасном листе бумаги.

2. Создайте класс в производственном коде и назовите его соответствующим образом.

3. Выберите одно поведение класса, который вы хотите реализовать, и создайте для него заглушку метода. С визуальной студией создание пустых меток - кусок пирога.

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

5. Скомпилируйте и пусть тестовый бегун покажет вам красную полосу!

6. Введите требуемое поведение в производственном коде, чтобы увидеть зеленую полосу.

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

Для этой процедуры две вещи очень важны:

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

Тест сначала или не первый тест?

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

Когда я модернизую тесты, необходимо выполнить громоздкое задание инициализации тестируемого объекта. Также утверждениями может быть много работы из-за запутанных зависимостей. Для этого вам нужно будет изменить производственный код и разбить зависимости. При правильной инъекции зависимостей это не должно быть проблемой.

Answer 8

Я предпочитаю подход KentBeck, который хорошо объясняется в книге «Испытательное развитие на примере» - Кент Бек.

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

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

Answer 9

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

Here is a tutorial application (в разделе «Учебник»), который показывает, какие тесты следует писать. В этом учебном пособии вы пишете код, чтобы передать предопределенные тестовые примеры, чтобы вы попали в ритм, а затем вы затем пишете свои собственные тесты. Файл README содержит инструкции. Он написан на Java, но вы можете легко адаптировать его к C#.

Answer 10

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

Я бы порекомендовал TDD - Test Driven Development. Это гарантирует, что у вас есть хороший охват, но он также фокусирует ваше внимание на правильном месте и проблемах.

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

Подумайте, что вы тестируете. Теперь запустите тест. Почему бы это не скомпилировать? Потому что вам нужен класс. Создайте класс и запустите тест. Почему он не компилируется? Потому что у него нет метода А. Напишите метод один и снова запустите единичный тест. Почему тест терпит неудачу? Потому что метод А не реализован. Внесите методА и выполните тест. Почему это терпит неудачу? Потому что метод А не возвращает правильное ожидаемое значение ... и т. Д.

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

Answer 11

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

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

Начать сначала тестирование; когда вам это очень удобно, и когда ваш код говорит вам, что вам нужны издевки, , то возьмите насмешки.

Answer 12

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

Answer 13

Распространение на ответ Стива Фримена: книга Дейва Астеля называется «Испытательная разработка - практическое руководство». Если вид приложения, который вы пишете, является графическим приложением, тогда это должно быть полезно. Я читал книгу Кента Беккса, но я не мог понять, как начать проект с TDD. Astel's book test - запускает полное нетривиальное графическое приложение от начала до конца, используя истории. Это очень помогло мне начать с TDD, он показал мне, где и как начать.

Answer 14

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

Хади Харири имеет отличный пост здесь http://hadihariri.com/2012/04/11/what-bdd-has-taught-me/

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

http://codecooked.com/introduction-to-unit-testing-and-test-driven-development/

http://codecooked.com/different-types-of-tests-and-which-ones-to-use/