Как структурировать проект во время модульного тестирования Qt-приложения QTestLib

Я получил свой проект Qt, и я использую Qt Creator. Я хочу выполнить все тесты кода. Однако я совершенно новый в рамках QTestLib, но все рекомендовали его для тестирования источника на основе Qt. Теперь я немного смущен, как структурировать тестовый проект с проектом приложения.

  • Можно ли разместить весь исходный код и тестовый код в том же проекте? Если да, то как я могу ими управлять? Я не нашел никакого варианта, который позволил бы мне начать приложение или начать тестирование в одном проекте.
  • Если я поставлю исходный код и тестовый код приложения в отдельных проектах, проект тестирования будет ссылаться на проект приложения, что не совсем удобно.
  • Для лотов для классов, которые необходимо протестировать, как мне управлять тестовым кодом?

Как вы, ребята, управляете тестированием кода в такой ситуации? Спасибо.

Ответы

Ответ 1

Первый источник структуры, как показано ниже:

MyApp
MyAppUnitTest

В проекте MyApp используйте MyAppSrc.pri для поиска исходных файлов:

SOURCES += \
    ../../../framework/src/myapp.cpp \
    ../../../framework/src/mycontrol.cpp

HEADERS += \
    ../../../framework/inc/myapp.h \
    ../../../framework/inc/mycontrol.h

INCLUDEPATH += ../../../framework/extlibs

Включите этот .pri в MyApp.pro, например:

include(MyAppSrc.pri)

Затем структурируйте проект тестирования точно так же, как и основной проект, с одним дополнительным включите в MyAppUnitTest.pro:

include(MyAppUnitTestSrc.pri)
include(../MyApp/MyAppSrc.pri)

Ответ 2

Я использую этот подход: http://xilexio.org/?p=125

А именно, поместите конфигурацию test в один файл .pro, который создает все. Иерархия файлов:

myproject.pro
src/
    Example1.cpp
    Example2.cpp
    Example1.h
    Example2.h
test/
    ExampleTest.cpp
    ExampleTest.h

myproject.pro файл:

QT += #needed modules

CONFIG += qt c++11

HEADERS += \
    src/Example1.h \
    src/Example2.h

SOURCES += \
    src/Example1.h \
    src/Example2.h

test{
    message(Configuring test build...)

    TEMPLATE = app
    TARGET = myapptests

    QT += testlib

    HEADERS += \
        test/ExampleTest.h

    SOURCES += \
        test/ExampleTest.cpp
}
else{
    TEMPLATE = lib
    TARGET = myapp

    CONFIG += plugin

    TARGET = $$qtLibraryTarget($$TARGET)
}

В моем примере я создаю библиотеку плагинов, но метод должен работать и для приложения. В случае приложения, вероятно, что SOURCES -= src/main.cpp требуется в соответствии с предложением else, библиотеки плагинов его не имеют. Если это не будет сделано, приложение main() приложения столкнется с main() модульных тестов.

ExampleTest.cpp выглядит следующим образом:

#include "ExampleTest.h"

void ExampleTest::exampleTest(){
    //Do the tests
}

QTEST_MAIN(ExampleTest)

ExampleTest.h выглядит следующим образом:

#include <QtTest/QtTest>

class ExampleTest : public QObject {
Q_OBJECT

private slots:
    void exampleTest();
};

Для создания тестов проекта в отдельном каталоге, чем обычная сборка, выполните:

qmake path/to/myproject.pro "CONFIG += test"

Ответ 3

Мне нравятся другие ответы, но я хотел бы также дать некоторые отзывы о том, как мы это делаем в компании, в которой я сейчас работаю:

  • Создайте проект subdirs (это будет проект верхнего уровня, который будет управлять ALL, включая проект библиотеки или все, что вы хотите проверить)

    +-----MyProject (top-level subdirs)

  • Добавьте свои проекты библиотек в качестве подпроекта

    +-----MyProject (top-level subdirs)
          |
          +-----Library (library project, UI project etc.)

  • Добавьте еще один проект subdirs (для тестов)

    +-----MyProject (top-level subdirs)
          |
          +-----Library (library project, UI project etc.)
          |
          +-----Tests (subdirs for tests)

  • Создайте проект QUnitTest, добавьте его в тестовый проект subdirs

    +-----MyProject (subdirs)
          |
          +-----Library (library project, UI project etc.)
          |
          +-----Tests (subdirs for tests)
                  |
                  +----- TestA (QUnitTest project for testing feature A)

  • Добавьте столько тестов, сколько хотите.

             ...
          |
          +-----Tests (subdirs for test)
                  |
                  +----- TestA (QUnitTest project for testing feature A)
                  |
                  +----- TestB (QUnitTest project for testing feature B)
                  |
                  +----- TestC (QUnitTest project for testing feature C)
                  |
                 ...
                  |
                  +----- TestZ (QUnitTest project for testing feature Z)

Если вам нужно групповое тестирование в группах, вы также можете использовать subdirs для этого. subdirs также обеспечивает создание реальных каталогов в вашей файловой системе. Если вы хотите избежать слишком большого количества subdirs ing, вы можете сгруппировать тесты в папках, которые вы создали самостоятельно, в своей файловой системе внутри папки проекта Tests.

Кроме того, я бы также рекомендовал добавить subdirs для проектов шаблонов.

+-----MyProject (subdirs)
          |
          +-----Library (library project, UI project etc.)
          |
          +-----Tests (subdirs for tests)
          |           |
          |          ...
          |
          +-----Templates (subdirs for template projects
                      |
                      +----- TemplateA (template project for feature A)
                      |
                      +----- TemplateB (template project for feature B)
                      |
                      +----- TemplateAB (template project for feature A and B together)
                      |
                     ...
                      |
                      +----- TemplateZ (template project for feature Z)

Это, конечно, основано на функциональности вашей библиотеки. В проектах шаблонов я имею в виду пользовательские виджеты и т.д., Которые связывают вашу библиотеку с выборочно (или все) ее функциональными возможностями так, как она должна казаться пользователю. Например, если у вас есть библиотека, которая управляет различными устройствами камеры, вы можете создать проект шаблонов для каждого устройства камеры, что позволит пользователям вашей библиотеки просто скопировать-вставить конкретный проект шаблона и расширить его или, по крайней мере, увидеть, как интеграция ваша библиотека должна произойти в целом. Это позволяет уменьшить документацию и в то же время дать приятные самодостаточные примеры, которые должны сократить время разработки, которое иначе потрачено на выяснение того, как работает интеграция и использование библиотеки (вы можете сказать, что это набор Hello World проектов:)). Наконец, но не в последнюю очередь вы можете очертить решения для разных случаев использования.

Ответ 4

Я использую Qt Creator от CMake вместо qmake для создания моего проекта Qt.

В основном у меня есть папки:

src
tests

Каждый тест - это сама программа, тестирующая класс. Приложение для тестирования компилируется как библиотека.. Вы компилируете все свои источники в папке src в качестве библиотеки.

// ClassTest.cpp
#include "ClassTest.h"
#include "Class2Test.h" // Class of the app

#include <QtTest/QtTest>

ClassTest::ClassTest( QObject* parent )
    : QObject(parent)
{ 
}

QTEST_MAIN( ClassTest )
#include "ClassTest.moc"

Вам просто нужно связать свою библиотеку с вашим тестовым исполняемым файлом.

Пример:

в папке src Пример CMakeLists.txt

add_library( MyAPP
    SHARED
    Class2Test.cpp
)
target_link_libraries( MyAPP
    ${QT_LIBRARIES}
)

в тестовой папке CMakeLists.txt, например, для каждого теста.

qt4_automoc( ${test_src} )
add_executable( ${test_name} ${test_src} )
target_link_libraries( ${test_name}
    MyAPP
    ${QT_LIBRARIES}
    ${QT_QTTEST_LIBRARY}
)

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