Запись модульных тестов позже

Я записал тесты после факта. Лучше поздно затем никогда. Их всегда стоит иметь.

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

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

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

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

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

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

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

Если Вы пишете тесты сначала...

Вы склонны писать код для установки тестам. Это поощряет "самую простую вещь, которая решает проблему" разработка типа и сохраняет Вас сфокусированными на решении проблемы, не работающей над метапроблемами.

Если Вы пишете код сначала...

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

Хотя я был бы удивлен, тестируют ли 1 программист из 50 ВСЕГДА записи сначала, я все еще утверждал бы, что это - что-то для борьбы за то, если Вы хотите записать хорошее программное обеспечение.

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

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

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

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

если Ваше использование другой среды тестирования затем MSUnitTest, довольно просто преобразовать затем тесты от MSUnit до Nunit, и т.д. просто сделайте некоторую копию и мимо.

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

"Я не совсем уверен, является ли это хорошим подходом (определенно не лучшее)".

Не очень? Почему нет?

Вы разрабатываете для тестируемости? В этом случае на Вашем дизайне делают пробную поездку. Что больше кто-либо может попросить?

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

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

Я хотел бы сказать, что я всегда пишу Модульные тесты сначала, но конечно я не делаю (по многочисленным причинам, известным любому настоящему программисту :-)). То, что я (хорошо, также не всегда...) делаю, должно преобразовать каждую ошибку, которая берет меня больше чем пять минут для нахождения в модульный тест. Даже, прежде чем я фиксирую его. Это имеет следующие преимущества:

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