Модульное тестирование на C / C ++: уроки, что запомнить?

Question

Модульное тестирование с C / C ++: Чему вы учите людей, которые либо раньше не проводили модульное тестирование, либо пришли из Java / Junit?

Какой самый важный урок / вещь, которую следует запомнить / отработать с вашей точки зрения, который экономит много времени и усилий (особенно в отношении C / C ++)?

Answer 1

1. Модульные тесты должны запускаться автоматически при каждой регистрации (или написанные и забытые модульные тесты не являются модульными).
2. Перед исправлением ошибки напишите модульный тест, чтобы выявить ее (она должна дать сбой). Затем исправьте ошибку и порадуйтесь, когда тест станет зеленым.
3. Можно пожертвовать немного «красотой» класса для облегчения тестирования (например, предоставить публичные методы, которые на самом деле не должны быть публичными, но помогают вашему тестированию / издевательству).

Answer 2

Прочитайте это ... вы все равно будете ..

Answer 3

Я против всех этих рекомендаций по автоматическому предоставлению дружбы на тестовые занятия ...

Лично я предпочитаю сосредоточиться на следующем, чтобы предоставить мне доступ к внутренностям класса, который мне нужно проверить:

1. Положитесь на общедоступный интерфейс класс, где это возможно; иногда это означает немного расширить публичный интерфейс, чтобы упростить тестирование. Не боритесь с этими расширениями слишком сильно, но и не позволяйте им слишком сильно управлять вашим дизайном ...
2. Рассмотрите возможность добавления интерфейса мониторинга, который может также использоваться «реальным» кодом в качестве тестового кода, чтобы включить мониторинг тестируемый код. (Я до сих пор удивляюсь тому, как часто это действительно хорошая часть процесса проектирования).
3. Рассмотрите возможность предоставления доступа к некоторым частям класса производным классам через «защищенный интерфейс» и получите «тестируемую» версию рассматриваемого класса, которая затем может быть инструментирована и протестирована.

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

Answer 4

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

Answer 5

Я бы хотел перефразировать ripper234 и добавить еще несколько правил:

1. Каждый модуль (обычно проект DLL) должен иметь отдельный проект UT. Все классы UT должны быть друзьями для всех классов DLL, к которым они имеют доступ для доступа к закрытым методам / членам.
2. Если вы хотите изменить модуль - сначала измените UT. Убедитесь, что и DLL, и ее UT-компиляция, ссылка и UT работают без сбоев и сбоев перед регистрацией. Нет необходимости запускать все UT для всех модулей перед каждой регистрацией - это пустая трата времени.
3. Все UT должны автоматически перестраиваться в ночной сборке вместе со всеми DLL. Все UT и модули должны компилироваться и связываться во время сборки.
4. Все UT должны автоматически запускаться после успешной ночной сборки, и результаты должны суммироваться.
5. Резюме со всеми результатами UT должно быть опубликовано разработчикам, и если есть какие-либо сбои или сбои, они должны быть исправлены как можно скорее.

Answer 6

Модульный тест должен проверять только одну вещь.

Я вижу гораздо чаще в C / C ++, чем в C # и Java, что модульные тесты тестируют целые рабочие процессы.

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

Answer 7

Один самый важный урок: тест лучше, чем отсутствие теста.