Как вы модифицируете модульные тесты в кодовую базу?

Question

Есть ли у вас какие-либо стратегии для переоборудования модульных тестов в базу кода, которая в настоящее время не имеет модульных тестов?

Answer 1

Чтение Эффективная работа с устаревшим кодом от Feathers .

У Джимми Богарда есть хорошая серия блогов на SOC .

Answer 2

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

Answer 3

Вот еще одна замечательная статья о тестировании. В частности, несколько актуальная цитата из него:

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

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

Answer 4

Почему вы хотите добавить юнит-тесты? Считаете ли вы, что в коде есть ошибки? Вы просто хотите что-то сделать? Вы собираетесь приступить к новой функции?

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

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

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

Answer 5

Если вы когда-нибудь пытаетесь добавить модульные тесты к старому Perl-коду, я настоятельно рекомендую

Тестирование Perl: записная книжка разработчика от Ian Langworth и chromatic.

У него есть очень хороший трюк при тестировании устаревшего и "непроверяемого" кода.

Answer 6

Дейл получает голосование. Да, нет смысла добавлять модульные тесты в работающий код. Допустим, есть две неизвестные ошибки X & Y. В какой-то момент X обнаруживается типичным полевым использованием. Вы исправляете это, добавляете юнит-тест и идете дальше. Теперь давайте предположим, что Y никогда не обнаруживается в течение всей жизни программы. Поскольку Y никогда не раскрывал себя, это как если бы оно никогда не существовало; не нужно тратить ресурсы. Умножьте это на сотни или тысячи неактивных ошибок, и вы избавите себя от лишнего обслуживания.

Answer 7

Возможно ли, что мы находимся в панике и запутываемся между юнит-тестами и тестами производительности? Это то, что ваше приложение отлично работает с несколькими пользователями, но начинает выдавать ошибки, когда под большой нагрузкой? Если это так, модульные тесты не являются ответом. Модульные тесты! = Нагрузочные тесты.

Если модульные тесты действительно являются ответом, то модернизация модульных тестов является хорошей идеей, поскольку она поможет очистить код. Просто будьте готовы к рефакторингу. Код, написанный с использованием TDD, выглядит сильно отличающимся от кода, написанного без TDD. В моем случае у меня был метод HandleDisposition (), который позаботился о многих случаях. Такой метод не существовал бы, если бы мы написали код с TDD. Когда мы модифицировали модульные тесты, мы реорганизовали эту функцию, и теперь у нас есть методы, такие как XDisposition (), YDisposition (), ZDisposition (), которые намного проще написать для модульных тестов.