Требуется мне добавить тестирование в один проект, никогда ранее тестированием не занимался, но прийдется.
Пока остановился на Google C++ Testing Framework, причины следующие:
1. Вера в Google.
2. Они все делают "просто" для конечного пользователя.
3. Все таки там работают лучшие умы человечества.
4. Есть надежда что проект будет нормально разиваться и сопровождаться.
Но, в инете мало информации, вернее нет ответов на мои вопросы, поэтому рискну задать вопросы здесь.
1. У меня MFC приложение (VS2008), я планирую построить тестирование следующим образом:
Добавть конфигурации TestDebug и TestRelease, сделать их консольными, и в tmain (будет
вызываться только для консоли) добавить вызов RUN_ALL_TESTS(). Тесты писать прямо в коде, рядом с
реализацией самой функции.
В проект добавил три файла gtest.h, gtest-all.cpp и gtest-main.cpp, добавил им precompillre headers, и все вроде работает.
Ну и вопросы:
Нормально ли что тестовый проект прямо внутри основного? -- Мне так проще, а как лучше?
Как исключить тесты из конфиигураций Debug и Release? -- Через #ifdef?
Как обязать разработчика пройти тест без ошибок перед Check-in'ом в TFS?
Как тестировать интерфейс? -- Подозреваю что его невозможно протестировать модульными тестами.
А может я изобретаю велосипед, и стандартное решение есть всему этому?
А может мне инструментарий поменять, или GTF вполне нормальный?
Здравствуйте, Malokhatko, Вы писали:
M>Добрый день Уважаемые Товарищи,
M>Требуется мне добавить тестирование в один проект, никогда ранее тестированием не занимался, но прийдется.
M>Пока остановился на Google C++ Testing Framework, причины следующие: M>1. Вера в Google. M>2. Они все делают "просто" для конечного пользователя. M>3. Все таки там работают лучшие умы человечества. M>4. Есть надежда что проект будет нормально разиваться и сопровождаться.
M>Но, в инете мало информации, вернее нет ответов на мои вопросы, поэтому рискну задать вопросы здесь.
M>1. У меня MFC приложение (VS2008), я планирую построить тестирование следующим образом: M>Добавть конфигурации TestDebug и TestRelease, сделать их консольными, и в tmain (будет M>вызываться только для консоли) добавить вызов RUN_ALL_TESTS(). Тесты писать прямо в коде, рядом с M>реализацией самой функции. M>В проект добавил три файла gtest.h, gtest-all.cpp и gtest-main.cpp, добавил им precompillre headers, и все вроде работает.
M>Ну и вопросы:
M>Нормально ли что тестовый проект прямо внутри основного? -- Мне так проще, а как лучше?
M>Как исключить тесты из конфиигураций Debug и Release? -- Через #ifdef?
M>Как обязать разработчика пройти тест без ошибок перед Check-in'ом в TFS?
M>Как тестировать интерфейс? -- Подозреваю что его невозможно протестировать модульными тестами.
M>А может я изобретаю велосипед, и стандартное решение есть всему этому?
M>А может мне инструментарий поменять, или GTF вполне нормальный?
Google C++ Testing Framework я не использовал, но могу поделиться своим опытом автоматизированного тестирования.
Для этого я применял Boost.Test. Мощный фрейворк. Основные фишки:
1. Тест — это отдельное приложение, которое в случае ошибки возвращает не ноль. Т.е уже можно организовать тестирование при сборке билда.
2. Все тесты можно представить в виде дерева. Так что можно запускать как отдельные ветки, подветки, так и одиночные тесты.
3. Поддерживает практически все что надо. Фикстуры, глобальные конфигурации, различные проверки и сравнения условий. По правде говоря, если исключить GUI, то я еще не сталкивался, что бы мне чего-то не хватало.
Еще я использовал тестовый фрейворк из Qt и из .Net. Что про них могу сказать. Qt позволяет тестировать GUI, но только написанное, как ни странно, на Qt. И еще там есть наборы данных для тестирования. Полезная вещь. .Net интегрирован в среду разработки, отсюда и плюшки, в виде запуска теста в котором сейчас находится курсор. Но без VS эти тесты очень трудно заставить работать.
И еще немного мыслей.
Держать тесты в коде основной программы очень плохая идея. С одной стороны, это документация. Но очень сильно загрязняет основной код. И еще. Тесты — это отдельное приложение. Его можно отдать клиенту, для тестирования твоих библиотек, или еще чего. Поэтому лучше отделять их сразу.
Re[2]: Google C++ Testing Framework, как применять?
Здравствуйте, Acteon, Вы писали:
A>Для этого я применял Boost.Test. Мощный фрейворк. Основные фишки:
завтра займусь изучением. Можно из Boosta "выкусить" только тестирование, что бы не таскать везде монстра?
A>1. Тест — это отдельное приложение, которое в случае ошибки возвращает не ноль. Т.е уже можно организовать тестирование при сборке билда.
Вопрос, на каждый билд автоматически запускать тесты (я так понял все), не сильно ли долго по времени?
A>2. Все тесты можно представить в виде дерева. Так что можно запускать как отдельные ветки, подветки, так и одиночные тесты.
Это весьма полезно, особенно при написании самих тестов, учту.
A>Держать тесты в коде основной программы очень плохая идея. С одной стороны, это документация. Но очень сильно загрязняет основной код. И еще. Тесты — это отдельное приложение. Его можно отдать клиенту, для тестирования твоих библиотек, или еще чего. Поэтому лучше отделять их сразу.
Тесты отдавать не будем, а код замусорит, это факт.
Вот я у себя в голове выложил некоторую концепцию, а Вы ее поломали, за это Вам и спасибо!
Re[3]: Google C++ Testing Framework, как применять?
> Вот я у себя в голове выложил некоторую концепцию, а Вы ее поломали, > за это Вам и спасибо!
Еще касательно тестов. Тесты должны быть отдельным приложением зависящим
от вашего приложения.
Тесты могут зависеть от чего угодно. В тестах можно использовать все!
Для запуска тестов у вас целая команда разработчиков!
У вашего приложения скорее всего совсем другие эксплуатационные требования.
Поэтому тесты на 100% должны быть отдельным приложением.
Posted via RSDN NNTP Server 2.1 beta
Re[4]: Google C++ Testing Framework, как применять?
Здравствуйте, Other Sam, Вы писали:
OS>Поэтому тесты на 100% должны быть отдельным приложением.
Да, но у нас проблема, проекту 7 лет, и он не сильно поддастся тестированию.
Хочется неспеша добавлять тесты на новую функциональность и на изменяемый код.
НО, в коде очень много зависимостей.
Получается что мне надо в мой тестовый проект добавлять все файлы из тестируемого проекта?
Спасибо.
Re[3]: Google C++ Testing Framework, как применять?
Здравствуйте, Malokhatko, Вы писали:
M>Здравствуйте, Acteon, Вы писали:
A>>Для этого я применял Boost.Test. Мощный фрейворк. Основные фишки: M>завтра займусь изучением. Можно из Boosta "выкусить" только тестирование, что бы не таскать везде монстра?
В теории возможно все. Практически, Boost.Test требует компиляции. Т.е можно сделать динамическую библиотеку и подключать ее в свои проекты. Я этого не делал, поэтому не знаю, будет ли легко.
A>>1. Тест — это отдельное приложение, которое в случае ошибки возвращает не ноль. Т.е уже можно организовать тестирование при сборке билда. M>Вопрос, на каждый билд автоматически запускать тесты (я так понял все), не сильно ли долго по времени?
A>>2. Все тесты можно представить в виде дерева. Так что можно запускать как отдельные ветки, подветки, так и одиночные тесты. M>Это весьма полезно, особенно при написании самих тестов, учту.
Boost.Test позволяет весьма выборочно запускать тесты, как я уже говорил выше. У меня у самого были тестирующие программы, которые под отладкой выполнялись по 10 минут. Толку от такой отладки.
A>>Держать тесты в коде основной программы очень плохая идея. С одной стороны, это документация. Но очень сильно загрязняет основной код. И еще. Тесты — это отдельное приложение. Его можно отдать клиенту, для тестирования твоих библиотек, или еще чего. Поэтому лучше отделять их сразу. M>Тесты отдавать не будем, а код замусорит, это факт.
Я тоже в свое время так думал, зачем пользователям тесты. Да, они не всегда нужны. По было пару проектов, где я должен был отдавать компоненты другим разработчикам. Вместе с ними, я передавал тесты, которые их тестируют (были еще тесты низкоуровневых компонент, естественно я их не отдавал). Очень удобно. Тебе говорят, что у тебя что-то не работает. А ты в ответ, тесты запустите. Все проходит? Прекрасно! Читайте документацию.
M> Вот я у себя в голове выложил некоторую концепцию, а Вы ее поломали, за это Вам и спасибо!
Да не за что. Путь тестов, правильный путь. Хоть и немного тернистый.
Re[5]: Google C++ Testing Framework, как применять?
Здравствуйте, Malokhatko, Вы писали:
M>Здравствуйте, Other Sam, Вы писали:
OS>>Поэтому тесты на 100% должны быть отдельным приложением.
M>Да, но у нас проблема, проекту 7 лет, и он не сильно поддастся тестированию. M>Хочется неспеша добавлять тесты на новую функциональность и на изменяемый код. M>НО, в коде очень много зависимостей.
M>Получается что мне надо в мой тестовый проект добавлять все файлы из тестируемого проекта?
M>Спасибо.
А вот с этим уже проблемы. Писать тесты на готовые приложения — задача намного сложнее. И самое обидное, что это все равно не позволит насладиться плодами автоматизированного тестирования — полной уверенности в работоспособности приложения лишь на основании прохождения всех тестов. Могу попытаться объяснить почему, но не думаю, что у меня хорошо получиться. Можно почитать про TDD (Test-Driven Development). Где-то в обсуждении этой техники подобный момент уже раскрывался.
Re[6]: Google C++ Testing Framework, как применять?
Здравствуйте, Acteon, Вы писали:
A>А вот с этим уже проблемы. Писать тесты на готовые приложения — задача намного сложнее. И самое обидное, что это все равно не позволит насладиться плодами ....
Понимаю и осознаю, но другого пути нет. Да, будет коряво, будет не в полном объеме, но все равно что то будет и что то можно будет выловить.
Re[7]: Google C++ Testing Framework, как применять?
Здравствуйте, Malokhatko, Вы писали:
M>Здравствуйте, Acteon, Вы писали:
A>>А вот с этим уже проблемы. Писать тесты на готовые приложения — задача намного сложнее. И самое обидное, что это все равно не позволит насладиться плодами .... M>Понимаю и осознаю, но другого пути нет. Да, будет коряво, будет не в полном объеме, но все равно что то будет и что то можно будет выловить.
Нет, я не в коем случае не отговариваю от написания тестов. Тесты — почти всегда хорошо. Просто для полноты картины. Ведь главное четко понимать, что ты делаешь, и зачем.
Re[3]: Google C++ Testing Framework, как применять?
Здравствуйте, Malokhatko, Вы писали:
M>завтра займусь изучением. Можно из Boosta "выкусить" только тестирование, что бы не таскать везде монстра?
А этим не стоит заниматься. Проще в проекте держать ссылки на исходники и либы.
Еще лучше если этот путь будет по умолчанию зафиксирован один или один для конкретной версии.
Буст имеет свойство обновляться и не стоит так сразу себя ограничивать ровно одной версией.
Этот аккаунт покинут.
Re[5]: Google C++ Testing Framework, как применять?
Здравствуйте, Malokhatko, Вы писали:
M>Здравствуйте, Other Sam, Вы писали:
OS>>Поэтому тесты на 100% должны быть отдельным приложением.
M>Да, но у нас проблема, проекту 7 лет, и он не сильно поддастся тестированию. M>Хочется неспеша добавлять тесты на новую функциональность и на изменяемый код. M>НО, в коде очень много зависимостей.
M>Получается что мне надо в мой тестовый проект добавлять все файлы из тестируемого проекта?
M>Спасибо.
Собрать тестируемые части как либы и линковать к тестовому проекту.
Если у вас там полное спагетти и в результате собираются 10К файлов мешанины из UI и BL в один *.exe — разбивать на модули и тестировать отдельно.