QtCreator сборка для тестирования

[deMax]

Как сделать отдельную сборку для тестирования? Т.е. как передать флаг тестирования #DEFINE TEST из настроек сборки в код.

Собираюсь писать проект с использованием TDD, и есть желание чтобы тесты запускались в отдельной сборке, в отдельной сборке отладка, в отдельной сборке релиз - чистая версия с удаленными через ifdef тестами.

[Swa]

В QtCreator на вкладке Projects создаёте сборку Test, далее в Build Steps -> Additional arguments добавляете

Код:

"DEFINES+=TEST"

. В коде ставите условия

Код:

#ifdef TEST
...
#endif

[deMax]

Swa, спасибо.

А если в папке с проектом создать папку test и внутри создать проект с тестами, можно ли будет вместо pri файла подсунуть pro файл? Как правильнее? Кто нибудь писал на Qt используя TDD?

[deMax]

А в файле pro как закомментировать папку с тестами? Или не нужно, так как если в main.c закоментированн include, то тесты в проект не попадут?

[qate]

> в отдельной сборке релиз - чистая версия с удаленными через ifdef тестами.

и вдруг повалили баги ...

считаю что всегда следует работать с релизом

[OKTA]

> в отдельной сборке релиз - чистая версия с удаленными через ifdef тестами.

и вдруг повалили баги ...

считаю что всегда следует работать с релизом

А дебажить как?

[b-s-a]

Никто не мешает добавить отладочную информацию в релизную сборку. Или сделать свою "релизную с дебажной информацией" (как в CMake: RelWithDebInfo). Но отлаживаться в этом режиме сущий ад - курсор скачет хаотично, а добрая половина переменных "соптимизирована".

[qate]

А дебажить как?

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

[OKTA]

А дебажить как?

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

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

[qate]

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

Не поверю.
Существует множество ситуаций, когда отладчик использовать невозможно, одна из них (и самая важная) - это работа программы на месте эксплуатации (в реальном железе). Или сетевое взаимодействие (когда остановиться невозможно) и т.д.

[OKTA]

Дебажить самые страшные баги нужно еще до работы на реальном железе иначе это не разработка программы, а нервный выкидыш  .
 И почему это нельзя остановить, когда идет работа с сетью?

[qate]

Дебажить самые страшные баги нужно еще до работы на реальном железе иначе это не разработка программы, а нервный выкидыш  .
 И почему это нельзя остановить, когда идет работа с сетью?

Часть багов конечно до релиза отлаживаются, но не все т.к. не учесть всех внешних факторов при разработке, которые будут в реальности
С сетью может быть простой баг по разным таймаутам, порядку обмена - лог это показывает сразу
Считаю, что выпускать программу без возможность лога - глупо (а раз есть лог, то отладчик не нужен)

[b-s-a]

Лог и отладчик это разные вещи. Попробуй по логам крах обнаружь. А отладчик тебе курсор на строчку поставит и бэктрейс покажет.

[lesav]

Попробуй по логам крах обнаружь. А отладчик тебе курсор на строчку поставит и бэктрейс покажет.

Можно писать программы и без крахов.  Все зависит от опыта программиста.
У меня был один проект(программно технический комплекс на QNX), в котором я совсем не использовал дебаггер, и чувствовал себя комфортно. 
Компилил в Windows, затем POST_LINKом по sftp заливал на таргет и запускал в терминале по ssh.

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

[b-s-a]

Если для тебя и твоего начальства время != деньги, то можно и не использовать отладчик.