Процесс тестирования приложения на C ++ и Qt - PullRequest
1 голос
/ 29 марта 2011

Я являюсь частью большого (вроде ...) приложения C ++, написанного в основном на Qt.Мне было интересно, если это правильный / общий подход: всякий раз, когда я вносить изменения в определенный / несколько исходных файлов, я компилирую его (QtCreator) в режиме отладки, а затем запускаю и тестирую его.проблема в том, что каждая компиляция занимает пару минут (обычно 1 - 3 минуты), я ненавижу это, и я предполагаю, что я делаю что-то не так, может быть, компиляция всего проекта для каждого незначительного изменения не является правильным путем кидти?

спасибо,

Ответы [ 4 ]

1 голос
/ 30 марта 2011

Попробуйте использовать модульный тест с QTest, насколько это возможно, затем вы можете сначала проверить детали, а затем дополнить их некоторым тестом для всего приложения.Это экономит много времени и может также помочь в создании более надежного кода, если все сделано правильно.

Для этого нужен какой-то модульный подход, поэтому код должен быть каким-то образом сгруппирован.

1 голос
/ 30 марта 2011

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

В общем, есть несколько подходов к тестированию, но вот две основные вещи, которые я бы порекомендовал:

  1. Не перестраивайте весь проект (без очистки, без перекомпоновки всего), просто делайте инкрементную сборку и тестируйте на ходу. Отлично подходит для тестирования изменений графического интерфейса и мелочей в проектах, которым не нужно ссылаться на миллион вещей или они долго запускаются.
  2. Разработайте его как отдельный проект с консольным приложением или простым тестовым приложением, которое вы не включите в окончательную интегрированную версию, но можете оставить для независимого тестирования позже. Это лучше для библиотек, таких как, скажем, вы создаете новый алгоритм шифрования или файловый менеджер, чтобы заменить старую архаичную часть большого проекта.

Конечно, всегда есть подход кодирования с подавляющей уверенностью, как сумасшедшего, и скрестив пальцы при компиляции и запуске, который очень популярен, но не настолько эффективен.

0 голосов
/ 27 ноября 2015

Также ответили в: Автоматизированное тестирование Qt

Я вместе со своей командой недавно разработал TUG, фреймворк с открытым исходным кодом для модульного тестирования графического интерфейса Qt.Использует Qt Test.Может быть, это поможет вам.

Видео лучше, чем тысяча слов: https://www.youtube.com/watch?v=tUis6JrycrA

Надеюсь, мы сможем сделать его лучше вместе.Github репо: http://pedromateo.github.io/tug_qt_unit_testing_fw/

0 голосов
/ 31 марта 2011

У вас есть несколько целей SUBDIRS в вашем проекте? Если ответ «да», вы можете попробовать настроить файл проекта, сначала удалив все «упорядоченные» ключевые слова из файлов проекта, а затем, если один вложенный каталог зависит от другого, объявите их как зависимости. И наконец, убедитесь, что вы передали значение -jX для make (то есть, если ваши правила сборки используют make), чтобы все ядра процессора использовались при компиляции.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...