Всетаки я еще не достиг просветления, и очень часто пишу код без тестов, потому что так быстрее/влом/проще/подствьте свой вариант...
Тесты должны прорабатывать быстро, но есть одна проблема - время компиляции. И в таком контексте я не на шутку задумался о сценариях сборки тестового раннера.
Идеальным для обычных приложений мне видится вариант, когда практически весь код приложения располагается в библиотеке. В принципе это не обязательно должна быть библиотека. Более быстрым может оказаться подход, который я наблюдал в linux ядре. Там модули аккумулируются в .o файлы.
Итак, весь код продукта аккумулируется в один модуль, который легко может быть слинкован как с main функцией продукта (которая по причине нетестированности должна быть минимальна), так и с тестовым раннером.
Вообще скорость надо померять. Ради скорости может иметь смысл все объектники раннера тоже слинковать, поскольку типичный сценарий TDD затрагивает то тесты, то код продукта. Но чтобы померять скорость - необходимо иметь достаточно объемный проект, разработанный в стиле TDD. У меня такого нету, я только учусь.
И учусь я вот на чем:
Одна из моих старых творений - это мое ядро, которое по истечении 10 лет все еще не готово. Но там вообще своя специфика. Там объектные модули продукта теоретически могут быть вообще не совместимы с текущей платформой, так что для тестирования их всеравно надо собрать под HOST.
Другая случай - это мой рабочий проект. В котором я поступил так: Я включил все исходники продукта в проект для тестирования, и они дважды собираются. Один раз при сборке бинарника продукта, другой раз при сборке тестового раннера. С тестированием там достаточно туго, но некоторые вещи удается потестировать.
Долго гуглил - но нигде не могу найти информацию о том, как люди разруливают тестирование и сборку в C++ проектах... Если не услышу более умного рецепта - буду изобретать свой велосипед.
Есть мысли пощупать Google test... каким он окажется в противовес boost?
Построить Qt из исходников под Linux
4 недели назад
3 коммент.:
ни одна библиотека для тестирования не поможет грамотно организовать проект.
у меня в проекте при постройке генерируются цель(исполняемый файл) и статическая библиотека.
статическая библиотека включается все объектники, кроме файла с main.
можно и функцию main переопределить через атрибут weak, но как-то лень.
Я собственно потому библиотеки и не упомянул, потому что в С++ по любому нужен отдельный тестовый раннер.
И мейн мешается, это да...
То есть это типа и емть стандартный путь? все в либу и юзаешь ее из теста и из мейна?
В принципе никаких особых минусов в такой схеме не наблюдается, только что проект фрагментируется. Да с тестами проект по любому фрагментируется.
http://www.youtube.com/watch?v=8Ut9o4OdSC0 может возникнут идеи :)
Отправить комментарий