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

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

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

Как вы справляетесь с тестированием кода в такой ситуации? Благодарю.

Источник

4 ответа

Решение

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

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)
Источник

Я использую этот подход: 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"
Источник

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

  1. Создать subdirs проект (это будет проект верхнего уровня, который будет управлять ВСЕМ, включая ваш библиотечный проект или все, что вы хотите протестировать)

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

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

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

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

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

  4. Создать QUnitTest проект добавить его к тестированию subdirs проект

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

  5. Добавьте столько тестов, сколько считаете нужным

             ...
          |
          +-----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Кроме того, вы можете сгруппировать тесты в папки, которые вы создали самостоятельно в своей файловой системе внутри 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 проекты:)). Не в последнюю очередь вы можете наметить решения для различных вариантов использования.

Источник

Я использую 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}
)

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

Источник
Другие вопросы по тегам