Как запустить поблочное тестирование или TDD?

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

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

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

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

Тесты не должны требовать настройки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. Скомпилируйте и позвольте средству выполнения тестов показать вам красную полосу!

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

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

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

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

Тестировать сначала или не тестировать первым?

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

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

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

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

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

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

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

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

Я бы порекомендовал TDD - Разработка через тестирование. Это обеспечивает хорошее покрытие, но при этом позволяет сосредоточить ваше внимание на нужном месте и проблеме.

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

Подумайте о том, что вы тестируете. Теперь запустим тест. Почему он не компилируется? Потому что вам нужен classA. Создайте класс и запустите тест. Почему не компилируется? Потому что у него нет метода A. Напишите первый метод и снова запустите модульный тест. Почему тест не проходит? Потому что methodA не реализован. Реализуйте methodA и запустите test. Почему не получается? Поскольку methodA не возвращает правильное ожидаемое значение ... и т. Д.

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

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

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

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

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

Кстати: window - это ссылка на глобальный объект в JavaScript браузера. Это также это , и должно работать даже в средах без браузера, таких как Node.js, расширения Chrome, транспилированный код и т. Д.

var obj = new this [classNameString] ();

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

var obj = (Function ('return new' + classNameString)) ()

Однако на самом деле нет причин использовать строку. Функции JavaScript сами по себе являются объектами, как и строки, которые также являются объектами.

Правка

Вот лучший способ получить глобальную область видимости, которая работает в строгом режиме, а также в средах JS без браузера:

var global;
try {
  global = Function('return this')() || (42, eval)('this');
} catch(e) {
  global = window;
}

// and then
var obj = new global[classNameString]

От:

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

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