Начало TDD-Проблемы? Решения? Рекомендации?

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

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

Принимая во внимание вышеизложенный абзац, давайте рассмотрим ваши вопросы:

1. Если я использую коллекцию в своей тестируемой системе, то я настрою ожидание, чтобы убедиться, что код был вызван для вставки элемента, а затем утверждать количество коллекции. Я не обязательно тестирую метод Add в своем внутреннем списке. Я просто удостоверяюсь, что он был вызван, когда вызывается метод, который добавляет элемент. Я делаю это, добавляя насмешливый фреймворк в смесь с моим тестовым фреймворком.
2. Тестирование строк в качестве выходных данных может быть утомительным. Вы не можете отчитываться за каждый результат. Вы можете проверить только то, что вы ожидаете, основываясь на функциональности тестируемой системы. Вы всегда должны разбивать свои тесты до самого маленького элемента, который он тестирует. Это означает, что у вас будет много тестов, но тестов, которые являются маленькими и быстрыми и проверяют только то, что они должны, и ничего больше.
3. Есть много платформ тестирования с открытым исходным кодом, чтобы выбрать из них. Я не собираюсь спорить, что лучше. Просто найдите тот, который вам нравится, и начните его использовать.
   • MbUnit
   • nUnit
   • xUnit
4. Все, что вы можете сделать, это настроить свои тесты для учета того, что вы хотите сделать. Если появляется сценарий, который вводит ошибку в вашу функциональность, по крайней мере, у вас есть тест вокруг функциональности, чтобы добавить этот сценарий в тест, а затем изменить свою функциональность, пока тест не пройдет. Один из способов найти место, где мы могли пропустить тест, - это использовать покрытие кода .

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

• Минимальный Заказ : Открытым Исходным Кодом
• RhinoMocks: Открытый Исходный Код
• TypeMock: Коммерческий Продукт
• NSubstitute: Открытый Исходный Код

Один из способов помочь в использовании TDD, помимо чтения о процессе, заключается в том, чтобы наблюдать, как люди это делают. Я рекомендую смотреть скринкасты по JP Будху на DNRTV . Проверить это:

• Жан Поль Будху о тестируемой разработке Часть 1
• Жан Поль Будху о тестируемой разработке Часть 2
• Жан Поль Будху о демистификации шаблонов дизайна Часть 1
• Жан Поль Будху о демистификации шаблонов дизайна Часть 2
• Жан Поль Будху о демистификации шаблонов дизайна Часть 3
• Жан Поль Будху о демистификации шаблонов дизайна Часть 4
• Жан Поль Будху о демистификации шаблонов дизайна Часть 5

OK, это поможет вам увидеть, как используются термины, которые я ввел. Он также представит еще один инструмент под названием Resharper и то, как он может облегчить процесс TDD. Я не мог рекомендовать этот инструмент достаточно, когда делал TDD. Кажется, что вы изучаете процесс, и вы просто находите некоторые из проблем, которые уже были решены с помощью других инструментов.

Я думаю, что поступил бы несправедливо по отношению к сообществу, если бы не обновил это, добавив новую серию Кента Бека о тестируемой разработке на прагматичном программисте .

Из моего собственного опыта:

1. Тестируйте только свой собственный код, а не код базовой платформы. Поэтому, если вы используете общий список, то нет необходимости тестировать добавление, удаление и т. д.

2. Нет никакого 2. Посмотри туда! Обезьяны!!!

3. NUnit - это путь, по которому нужно идти.

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

Мой взгляд на это следующий:

• +1 для того, чтобы не тестировать код фреймворка, но вам все равно может понадобиться протестировать классы, производные от классов фреймворка.
• Если какой-то класс/метод является громоздким для тестирования, это может быть сильным признаком того, что что-то не так с desing. Я стараюсь следовать принципу "1 class - 1 responsibility, 1 method - 1 action". Таким образом, Вы сможете гораздо легче тестировать сложные методы, делая это меньшими порциями.
• +1 за xUnit. Для Java вы можете также рассмотреть TestNG .
• TDD - это не единичное событие, это процесс. Поэтому не пытайтесь представить себе все с самого начала, но убедитесь, что каждая ошибка, обнаруженная в коде, действительно покрывается тестом после обнаружения.

Я думаю, что самая важная вещь (и фактически один из великих результатов, в некотором рекурсивном смысле) TDD-это успешное управление зависимостями. Вы должны убедиться, что модули тестируются изолированно, без какой-либо сложной настройки. Например, если вы тестируете компонент, который в конечном итоге отправляет email, сделайте отправителя email зависимостью, чтобы вы могли имитировать его в своих тестах. Это приводит ко второму пункту - насмешники - ваши друзья. Познакомьтесь с издевательскими фреймворками и стилем тестов, которые они продвигают (поведенческий, в отличие от классического состояния), а также с выбором дизайна, который они поощряют (принцип "Tell, don't ask" ).

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

Во всяком случае, чтобы ответить на ваши вопросы

1. Вам не нужно проверять то, что вы "know" собираетесь работать, если только вы не написали это. Вы не писали дженерики, это сделала Microsoft ;)
2. Если вам нужно сделать так много для вашего теста, возможно, ваш объект/метод тоже делает слишком много.
3. Загрузите TestDriven.NET , чтобы немедленно начать модульное тестирование в Visual Studio (за исключением случаев, когда это экспресс-выпуск)
4. Просто проверьте правильность того, что произойдет . Вам не нужно проверять все, что может пойти не так: вы должны ждать, пока ваши тесты не провалятся для этого.

Серьезно, просто сделай это, чувак. :)

Я ни в коем случае не эксперт по TDD, но вот мое мнение:

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

Фреймворки тестирования xUnit часто можно использовать бесплатно, так что если вы .Net парень, проверьте NUnit, а если Java-это ваша вещь, проверьте JUnit.

Вышеприведенный совет хорош, и если вы хотите получить список свободных фреймворков, вам нужно смотреть не дальше списка фреймворков xUnit в Википедии. Надеюсь, это поможет :)

По моему мнению (ваш пробег может отличаться):

1-Если вы не написали его, не тестируйте его. Если вы написали его, и у вас нет для него теста, он не существует.

3 - как все говорят, xUnit-это бесплатно и здорово.

2 & 4 - точно решить, что именно нужно проверить, - это одна из тех вещей, о которых вы можете спорить с самим собой вечно. Я стараюсь провести эту линию, используя принципы проектирования по контракту. Проверьте "объектно-ориентированное программное обеспечение" или "The Pragmatic Programmer" для получения подробной информации о нем.

Держите тесты короткими, "atomic". Проверьте наименьшее предположение в каждом тесте. Сделайте каждый TestMethod независимым, для интеграционных тестов я даже создаю новую базу данных для каждого метода. Если вам нужно построить некоторые данные для каждого теста, используйте метод "Init". Используйте mocks, чтобы изолировать класс, который вы тестируете, от его зависимостей.

Я всегда думаю: "Какой минимальный объем кода мне нужно написать, чтобы доказать, что это работает для всех случаев ?"

За последний год я все больше и больше убеждался в пользе TDD. То, чему я научился на своем пути: 1) инъекция зависимости - ваш друг. Я не говорю об инверсии управляющих контейнеров и фреймворков для сборки плагиновых архитектур, просто передаю зависимости в конструктор тестируемого объекта. Это окупает огромные дивиденды в тестируемости вашего кода. 2) я отправился со страстью / фанатизмом новообращенного и схватил насмешливую структуру и начал использовать насмешки для всего, что я мог. Это привело к хрупким тестам, которые требовали много болезненных настроек и падали, как только я начинал какой-либо рефакторинг. Используйте правильный вид теста double. Подделки, где вам просто нужно соблюдать интерфейс, заглушки для передачи данных обратно в тестируемый объект, подделка только там, где вы заботитесь о взаимодействии. 3) тест должен быть небольшим. Стремитесь к тому, чтобы в каждом тесте проверялось одно утверждение или взаимодействие. Я стараюсь делать это, и в основном я там. Речь идет о надежности тестового кода, а также о степени сложности теста, когда вам нужно будет вернуться к нему позже.

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

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

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

Надеюсь, это поможет! :)