Первый TDD, простой 2-уровневый проект на C # - что мне тестировать?

Question

Это, вероятно, глупый вопрос, но мой поиск в Google не находит удовлетворительного ответа. Я начинаю небольшой проект на C #, только с бизнес-уровнем и уровнем доступа к данным - странно, пользовательский интерфейс появится позже, и у меня очень мало (читай: нет) концепции / контроля над тем, как это будет выглядеть.

Я бы хотел попробовать TDD для этого проекта. Я использую Visual Studio 2008 (скоро будет 2010), у меня есть ReSharper 5 и nUnit.

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

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

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

Заранее спасибо за любые рекомендации!

Answer 1

Испытание кажется контрпродуктивным вещи, которые не имеют причины потерпеть неудачу (авто-свойства, пусто Конструкторы) ...

Это ... Нет логики в пустом конструкторе или авто-свойстве для тестирования.

когда я пишу первый модульный тест?

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

где мне написать первый модульный тест?

В первом тестовом классе, который вы создаете.

Это, пожалуй, лучший онлайн-ресурс:

Введение в тестовую конструкцию (TDD)
http://www.agiledata.org/essays/tdd.html

Answer 2

Испытание кажется контрпродуктивным вещи, которые не имеют причины потерпеть неудачу (авто-свойства, пусто Конструкторы) ...

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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