2011-01-25 3 views
8

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

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

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

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

+2

«Я знаю, что многие люди говорят, что обычно не стоит добавлять модульные тесты к существующему коду ...» <- вам нужно выбрать разных людей для прослушивания. Просто говорю'. –

ответ

6

В то время как книга Мартина Фаулера по рефакторингу является сокровищницей информации, почему бы не взглянуть на «Working Effectively with Legacy Code».

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

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

1

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

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

Класса, который трудно модульное тестирование будет один, что

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

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

Поскольку вы решили реорганизовать свои классы, попробуйте использовать подход BDD или TDD.

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

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

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

Решение обычно заключается в развертывании большого количества TLA – CashCow

+1

@CashCow TLAs? Что означает TLA? –

0

Я думаю, что если вам нужно придумать «меру», чтобы проверить, проверен ли класс, вы уже были fscked. Вы должны быть в состоянии сказать, просто посмотрев на него: можете ли вы написать независимую программу, которая ссылается только на этот класс и убедится, что это работает?

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

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

0

Мы в IPL опубликовали статью It's testing Jim, but not as we know it, в которой рассматриваются практические проблемы тестирования C++ и предлагаются некоторые методы их решения, которые могут быть полезны с учетом вашего вопроса. Эти методы также хорошо поддерживаются в Cantata ++ - нашем инструменте C/C++ и интеграционном тестировании.

Смежные вопросы