Google C++ Testing Framework, как применять?
От: Malokhatko  
Дата: 18.05.10 12:17
Оценка:
Добрый день Уважаемые Товарищи,

Требуется мне добавить тестирование в один проект, никогда ранее тестированием не занимался, но прийдется.

Пока остановился на 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 вполне нормальный?
Re: Google C++ Testing Framework, как применять?
От: Acteon  
Дата: 18.05.10 12:52
Оценка: 2 (1)
Здравствуйте, 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, как применять?
От: Malokhatko  
Дата: 18.05.10 14:04
Оценка:
Здравствуйте, Acteon, Вы писали:

A>Для этого я применял Boost.Test. Мощный фрейворк. Основные фишки:

завтра займусь изучением. Можно из Boosta "выкусить" только тестирование, что бы не таскать везде монстра?

A>1. Тест — это отдельное приложение, которое в случае ошибки возвращает не ноль. Т.е уже можно организовать тестирование при сборке билда.

Вопрос, на каждый билд автоматически запускать тесты (я так понял все), не сильно ли долго по времени?

A>2. Все тесты можно представить в виде дерева. Так что можно запускать как отдельные ветки, подветки, так и одиночные тесты.

Это весьма полезно, особенно при написании самих тестов, учту.

A>Держать тесты в коде основной программы очень плохая идея. С одной стороны, это документация. Но очень сильно загрязняет основной код. И еще. Тесты — это отдельное приложение. Его можно отдать клиенту, для тестирования твоих библиотек, или еще чего. Поэтому лучше отделять их сразу.

Тесты отдавать не будем, а код замусорит, это факт.

Вот я у себя в голове выложил некоторую концепцию, а Вы ее поломали, за это Вам и спасибо!
Re[3]: Google C++ Testing Framework, как применять?
От: Other Sam Россия  
Дата: 18.05.10 14:22
Оценка:
> Вот я у себя в голове выложил некоторую концепцию, а Вы ее поломали,
> за это Вам и спасибо!

Еще касательно тестов. Тесты должны быть отдельным приложением зависящим
от вашего приложения.
Тесты могут зависеть от чего угодно. В тестах можно использовать все!
Для запуска тестов у вас целая команда разработчиков!
У вашего приложения скорее всего совсем другие эксплуатационные требования.
Поэтому тесты на 100% должны быть отдельным приложением.
Posted via RSDN NNTP Server 2.1 beta
Re[4]: Google C++ Testing Framework, как применять?
От: Malokhatko  
Дата: 18.05.10 14:56
Оценка:
Здравствуйте, Other Sam, Вы писали:

OS>Поэтому тесты на 100% должны быть отдельным приложением.


Да, но у нас проблема, проекту 7 лет, и он не сильно поддастся тестированию.
Хочется неспеша добавлять тесты на новую функциональность и на изменяемый код.
НО, в коде очень много зависимостей.

Получается что мне надо в мой тестовый проект добавлять все файлы из тестируемого проекта?

Спасибо.
Re[3]: Google C++ Testing Framework, как применять?
От: Acteon  
Дата: 18.05.10 14:58
Оценка:
Здравствуйте, 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, как применять?
От: Acteon  
Дата: 18.05.10 15:03
Оценка:
Здравствуйте, Malokhatko, Вы писали:

M>Здравствуйте, Other Sam, Вы писали:


OS>>Поэтому тесты на 100% должны быть отдельным приложением.


M>Да, но у нас проблема, проекту 7 лет, и он не сильно поддастся тестированию.

M>Хочется неспеша добавлять тесты на новую функциональность и на изменяемый код.
M>НО, в коде очень много зависимостей.

M>Получается что мне надо в мой тестовый проект добавлять все файлы из тестируемого проекта?


M>Спасибо.


А вот с этим уже проблемы. Писать тесты на готовые приложения — задача намного сложнее. И самое обидное, что это все равно не позволит насладиться плодами автоматизированного тестирования — полной уверенности в работоспособности приложения лишь на основании прохождения всех тестов. Могу попытаться объяснить почему, но не думаю, что у меня хорошо получиться. Можно почитать про TDD (Test-Driven Development). Где-то в обсуждении этой техники подобный момент уже раскрывался.
Re[6]: Google C++ Testing Framework, как применять?
От: Malokhatko  
Дата: 19.05.10 07:06
Оценка:
Здравствуйте, Acteon, Вы писали:

A>А вот с этим уже проблемы. Писать тесты на готовые приложения — задача намного сложнее. И самое обидное, что это все равно не позволит насладиться плодами ....

Понимаю и осознаю, но другого пути нет. Да, будет коряво, будет не в полном объеме, но все равно что то будет и что то можно будет выловить.
Re[7]: Google C++ Testing Framework, как применять?
От: Acteon  
Дата: 19.05.10 07:39
Оценка:
Здравствуйте, Malokhatko, Вы писали:

M>Здравствуйте, Acteon, Вы писали:


A>>А вот с этим уже проблемы. Писать тесты на готовые приложения — задача намного сложнее. И самое обидное, что это все равно не позволит насладиться плодами ....

M>Понимаю и осознаю, но другого пути нет. Да, будет коряво, будет не в полном объеме, но все равно что то будет и что то можно будет выловить.

Нет, я не в коем случае не отговариваю от написания тестов. Тесты — почти всегда хорошо. Просто для полноты картины. Ведь главное четко понимать, что ты делаешь, и зачем.
Re[3]: Google C++ Testing Framework, как применять?
От: Head Ache  
Дата: 30.09.10 03:27
Оценка:
Здравствуйте, Malokhatko, Вы писали:

M>завтра займусь изучением. Можно из Boosta "выкусить" только тестирование, что бы не таскать везде монстра?


А этим не стоит заниматься. Проще в проекте держать ссылки на исходники и либы.
Еще лучше если этот путь будет по умолчанию зафиксирован один или один для конкретной версии.
Буст имеет свойство обновляться и не стоит так сразу себя ограничивать ровно одной версией.
Этот аккаунт покинут.
Re[5]: Google C++ Testing Framework, как применять?
От: blackhearted Украина  
Дата: 17.01.11 09:51
Оценка:
Здравствуйте, Malokhatko, Вы писали:

M>Здравствуйте, Other Sam, Вы писали:


OS>>Поэтому тесты на 100% должны быть отдельным приложением.


M>Да, но у нас проблема, проекту 7 лет, и он не сильно поддастся тестированию.

M>Хочется неспеша добавлять тесты на новую функциональность и на изменяемый код.
M>НО, в коде очень много зависимостей.

M>Получается что мне надо в мой тестовый проект добавлять все файлы из тестируемого проекта?


M>Спасибо.


Собрать тестируемые части как либы и линковать к тестовому проекту.
Если у вас там полное спагетти и в результате собираются 10К файлов мешанины из UI и BL в один *.exe — разбивать на модули и тестировать отдельно.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.