Да, а почему же Inline-тестирование лучше, чем обычное Unit-тестирование?
Есть сразу несколько причин:
- Тесты пишутся буквально в том же месте, что и сам код. Тесты также частично поясняют код.
- Не нужны отдельные классы, создание теста ускоряется, и неразделимо по времени со временем создания кода.
- Не требуется инициализация класса, который содержит даный код. Тест использует только минимальный кусок кода.
- Мы можем автоматически (и без дополнительных средств) проверить, что все ветви исполнения обходятся тестами.
Но Inline-тестирование – это тоже не идеально:
- Подходят для тестирования небольших и неочевидных кусков кода на низком уровне, для всего остального лучше использовать Unit-тесты.
- Сильно загрязняют код и ухудшают его читаемость. При этом, чем больше test-case-ов, тем больше строк кода уходит на тестирование.
В итоге, я пришел к схеме с несколькими уровнями тестов для своего проекта:
- Inline-тесты для небольших сложных кусков кода;
- Unit-тесты для тестирования большинства классов;
- Функциональные тестовые скрипты.
Первые два вида удалось интегрировать с помощью библиотеки cppunit, и встроить в процесс сборки.
