Pregunta Cómo estructurar un proyecto mientras se prueba la unidad de la aplicación Qt de QTestLib


Obtuve mi proyecto de Qt y estoy usando Qt Creator. Quiero hacer una prueba unitaria de todo mi código.
Sin embargo, soy bastante nuevo en el marco de QTestLib, pero todos lo recomendaron para probar la fuente basada en Qt. Ahora estoy un poco confundido sobre cómo estructurar el proyecto de prueba con el proyecto de la aplicación.

  1. ¿Puedo poner todos los códigos fuente y prueba en el mismo proyecto? Si es así, ¿cómo podría gestionarlos? No encontré ninguna opción que me permita iniciar la aplicación o iniciar la prueba en un proyecto.
  2. Si pongo el código fuente y de prueba de la aplicación en proyectos separados, el proyecto de prueba hará referencia al proyecto de la aplicación, eso no es muy conveniente.
  3. Para lotes para clases que se deben probar, ¿cómo administro el código de prueba?

¿Cómo manejan el código de prueba en tal situación? Gracias.


32
2017-08-28 07:54


origen


Respuestas:


Primera fuente de estructura como a continuación:

MyApp
MyAppUnitTest

Debajo MyApp proyecto, use un MyAppSrc.pri para localizar archivos fuente:

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

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

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

Incluir esto .pri en MyApp.pro me gusta:

include(MyAppSrc.pri)

Luego, estructure el proyecto de prueba exactamente como el proyecto principal, con una inclusión adicional en MyAppUnitTest.pro:

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

15
2017-12-25 02:46



Yo uso este enfoque: http://xilexio.org/?p=125

A saber, coloca un test config en el single .pro archivo que construye todo. Jerarquía de archivos:

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

myproject.pro archivo:

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)
}

En mi ejemplo, estoy creando una biblioteca de complementos, pero el método también debería funcionar para una aplicación. En el caso de una aplicación, es probable que SOURCES -= src/main.cpp es necesario bajo el else cláusula, las bibliotecas de complementos no lo tienen. Si esto no se hace, el main() de la aplicación chocará con el main() de las pruebas unitarias

ExampleTest.cpp se parece a lo siguiente:

#include "ExampleTest.h"

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

QTEST_MAIN(ExampleTest)

ExampleTest.h se parece a lo siguiente:

#include <QtTest/QtTest>

class ExampleTest : public QObject {
Q_OBJECT

private slots:
    void exampleTest();
};

Para crear las pruebas del proyecto, en un directorio aparte de la compilación normal, ejecute:

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

7
2018-04-29 09:25



Me gustan las otras respuestas, pero también me gustaría comentar cómo lo hacemos en la empresa en la que trabajo actualmente:

  1. Crear un subdirs proyecto (este será el proyecto de nivel superior que administrará TODO incluyendo su proyecto de biblioteca o lo que sea que quiera probar)

    +-----MyProject (top-level subdirs)
    
  2. Agregue sus proyectos de biblioteca como un subproyecto

    +-----MyProject (top-level subdirs)
              |
              +-----Library (library project, UI project etc.)
    
  3. Agrega otro subdirs proyectos (para las pruebas)

    +-----MyProject (top-level subdirs)
              |
              +-----Library (library project, UI project etc.)
              |
              +-----Tests (subdirs for tests)
    
  4. Crear un QUnitTest proyectar y agregarlo a las pruebas subdirs proyecto

    +-----MyProject (subdirs)
              |
              +-----Library (library project, UI project etc.)
              |
              +-----Tests (subdirs for tests)
                      |
                      +----- TestA (QUnitTest project for testing feature A)
    
  5. Agregue tantas pruebas como crea conveniente

             ...
              |
              +-----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)
    

Si necesita agrupar la prueba en grupos, también puede usar subdirs Para hacer eso. subdirs también asegura la creación de real directorios en su sistema de archivos. Si quieres evitar demasiado subdirsPuede agrupar las pruebas en carpetas que ha creado por su cuenta en su sistema de archivos dentro del Tests carpeta de proyecto.

Además de eso, también recomendaría agregar un subdirs para proyectos de plantillas.

+-----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)

Por supuesto, esto se basa en la funcionalidad de su biblioteca. Con los proyectos de plantillas quiero decir widgets personalizados, etc., que enlazan con su biblioteca y exponen selectivamente (o todas) su funcionalidad de la manera en que se supone que debe aparecerle al usuario. Por ejemplo, si tiene una biblioteca que maneja varios dispositivos de cámara, puede crear un proyecto de plantilla para cada dispositivo de cámara, permitiendo así a los usuarios de su biblioteca copiar y pegar el proyecto de plantilla específico y expandirlo o al menos ver cómo la integración de su biblioteca se supone que suceda en general. Esto permite reducir la documentación y, al mismo tiempo, dar buenos ejemplos autónomos que deberían reducir el tiempo de desarrollo que de otro modo se gastaría en descubrir cómo funciona la integración y el uso de la biblioteca (se puede decir que es una especie de conjunto de Hello World). proyectos :)). Por último, pero no menos importante, puede delinear soluciones para diferentes casos de uso.


4
2017-11-02 12:40



Yo uso Qt Creator de CMake en lugar de qmake para construir mi proyecto de Qt.

Básicamente tengo a las carpetas:

src
tests

Cada prueba es un programa en sí mismo que prueba una clase. La aplicación que se probará se compilará como una biblioteca.. Usted compila todas sus fuentes en la carpeta src como una biblioteca.

// 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"

Solo tienes que vincular tu lib a tu ejecutable de prueba.

Ejemplo:

en la carpeta src Ejemplo de CMakeLists.txt

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

en la carpeta de pruebas del ejemplo de CMakeLists.txt, para cada prueba.

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

Todavía está en el mismo proyecto pero puede agregar una bandera para permitir que el usuario compile la prueba o no. Está limpio porque la aplicación se mantiene intacta y le permite probar cada clase de su aplicación.


1
2017-12-21 23:56