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

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

При работе с коллекциями, все равно будет проверяться на то, что явные добавления/удаления/вставки будут успешными, даже если они основаны на Generics и т.д., где мы "знаем", что он будет работать?
Некоторые тесты, по-видимому, навсегда реализуются. Например, когда вы работаете со строковым выходом, есть ли "лучший" способ заниматься такими вещами? (например, протестируйте модель объекта перед разбором, разбейте анализ на небольшие операционные системы и проверьте там). На мой взгляд, вы всегда должны проверять "конечный результат", но это может сильно варьироваться и быть утомительным для настройки.
У меня нет рамки для тестирования (я не буду платить за нее), поэтому я могу "попрактиковаться" больше. Есть ли хорошие, которые бесплатны для коммерческого использования? (на данный момент я использую good 'ol Debug.Assert:)
Наверное, самый большой.. Иногда я не знаю, чего ожидать НЕ произойдет. Я имею в виду, вы получаете свой зеленый свет, но я всегда обеспокоен тем, что мне не хватает теста. Вы копаете глубже, чтобы попробовать и сломайте код, или оставьте его и дождитесь, пока все это упадет позже (что будет стоить дороже).

Таким образом, в основном то, что я ищу здесь, - это не просто "просто сделай это", а "Я сделал это, у меня были проблемы с этим, решил их этим". Опыт личного:)

Ответ 1

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

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

Принимая во внимание вышеуказанный пункт, давайте рассмотрим ваши вопросы:

Если я использую коллекцию в своей тестируемой системе, то я настрою ожидание, чтобы убедиться, что код был вызван, чтобы вставить элемент, а затем утвердить подсчет коллекции. Я не обязательно проверяю метод "Добавить" в своем внутреннем списке. Я просто убеждаюсь, что он был вызван, когда вызывается метод, который добавляет элемент. Я делаю это, добавляя фальшивую фреймворк в микс с моей платформой тестирования.
Тестирование строк в качестве вывода может быть утомительным. Вы не можете объяснить каждый результат. Вы можете проверить только то, что вы ожидаете, на основе функциональности тестируемой системы. Вы всегда должны прерывать тесты до самого маленького элемента, который он тестирует. Это означает, что у вас будет много тестов, но тесты, которые бывают маленькими и быстрыми, и проверяйте только то, что им нужно, ничто другое.
На платформе для тестирования с открытым исходным кодом существует множество вариантов. Я не буду спорить, что лучше. Просто найдите тот, который вам нравится, и начните его использовать.
- MbUnit
- nUnit
- xUnit
Все, что вы можете сделать, это настроить свои тесты для учета того, что вы хотите. Если возникает сценарий, который вводит ошибку в вашу функциональность, по крайней мере, у вас есть тест вокруг функциональности, чтобы добавить этот сценарий в тест, а затем измените свою функциональность до тех пор, пока тест не пройдет. Одним из способов найти, где мы, возможно, пропустили тест, является использование покрытия кода.

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

Moq: Open Source
RhinoMocks: с открытым исходным кодом
TypeMock: Коммерческий продукт
NSubstitute: с открытым исходным кодом

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

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

Я думаю, что я буду делать несправедливость для сообщества, если бы не обновил это, добавив новую серию Кент Бек на Test Driven Development for Pragmatic Программист.

Ответ 2

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

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

Ответ 3

Я беру на себя следующее:

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

Ответ 4

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

Ответ 5

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

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

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

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

Ответ 6

Я не эксперт в TDD, никоим образом, но вот мое мнение:

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

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

Ответ 7

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

Ответ 8

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

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

3- Как сказали все, xUnit свободный и отличный.

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

Ответ 9

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

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

Ответ 10

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

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

Ответ 11

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

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

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