У тебя TDD для отладки починить?

Question

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

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

1. Так что TDD подходит для отладки тоже
2. Или есть есть другой метод или ресурс / книга это было бы более полезным для этого Цель
3. Я больше беспокоюсь о Интеграционный тест часть, как я упомянутое выше. я ищу все, что связано с LAMP / Axkit / Perl Метод.

Спасибо.

Answer 1

1. Написать тест, который не проходит из-за баг.
2. Исправьте ошибку в вашем коде.
3. Перезапустить тест.
4. Перезапустить все тесты.

Так что - да - очень сильно.

Answer 2

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

Answer 3

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

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

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

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

UPDATE: В Extreme Perl .

есть глава о модульном тестировании в Perl.

Answer 4

Короче, ответ - да. Основная структура этого процесса - написать контрольный пример, который бы имитировал ошибку и провалил контрольный пример. Затем исправьте ошибку, которая прошла бы тестовый набор.

Answer 5

Да. Конечно, все тесты, которые вы выполняли во время TDD вашего выпуска, будут добавлены в набор регрессионных тестов. Но в случае ошибки этот набор регрессий явно не был достаточно подробным.

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

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

Answer 6

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

Это будет означать, что тесты будут выполняться медленнее, а поведение будет искажено вашими ошибочными тестами.

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

Я думаю, что важно различать два.

Answer 7

Я всегда писал тесты перед реальным кодом при исправлении ошибки.

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

Answer 8

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