четверг, 30 сентября 2010 г.

Использование юниттестов

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

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

Идеальным для обычных приложений мне видится вариант, когда практически весь код приложения располагается в библиотеке. В принципе это не обязательно должна быть библиотека. Более быстрым может оказаться подход, который я наблюдал в linux ядре. Там модули аккумулируются в .o файлы.

Итак, весь код продукта аккумулируется в один модуль, который легко может быть слинкован как с main функцией продукта (которая по причине нетестированности должна быть минимальна), так и с тестовым раннером.

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

И учусь я вот на чем:

Одна из моих старых творений - это мое ядро, которое по истечении 10 лет все еще не готово. Но там вообще своя специфика. Там объектные модули продукта теоретически могут быть вообще не совместимы с текущей платформой, так что для тестирования их всеравно надо собрать под HOST.

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

Долго гуглил - но нигде не могу найти информацию о том, как люди разруливают тестирование и сборку в C++ проектах... Если не услышу более умного рецепта - буду изобретать свой велосипед.

Есть мысли пощупать Google test... каким он окажется в противовес boost?