qtest - qt testing
Cómo estructurar un proyecto mientras se prueba la unidad de la aplicación Qt de QTestLib (4)
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.
- ¿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.
- 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.
- 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.
Me gustan las otras respuestas, pero también me gustaría comentar cómo lo hacemos en la empresa en la que trabajo actualmente:
Crea un proyecto de
subdirs(este será el proyecto de nivel superior que administrará TODO, incluido tu proyecto de biblioteca o lo que quieras probar)+-----MyProject (top-level subdirs)Agregue sus proyectos de biblioteca como un subproyecto
+-----MyProject (top-level subdirs) | +-----Library (library project, UI project etc.)Agregar otros proyectos de
subdirs(para las pruebas)+-----MyProject (top-level subdirs) | +-----Library (library project, UI project etc.) | +-----Tests (subdirs for tests)Cree un proyecto
QUnitTestyQUnitTestproyecto desubdirsprueba+-----MyProject (subdirs) | +-----Library (library project, UI project etc.) | +-----Tests (subdirs for tests) | +----- TestA (QUnitTest project for testing feature A)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 hacerlo. subdirs también asegura la creación de directorios reales en su sistema de archivos. Si desea evitar demasiadas subdirs , puede agrupar las pruebas en carpetas que haya creado por su cuenta en su sistema de archivos dentro de la carpeta del proyecto Tests .
Además de eso, también recomendaría agregar un subdirs para proyectos de plantilla .
+-----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.
Primera fuente de estructura como a continuación:
MyApp
MyAppUnitTest
En MyApp proyecto MyApp , use un MyAppSrc.pri para localizar los archivos fuente:
SOURCES += /
../../../framework/src/myapp.cpp /
../../../framework/src/mycontrol.cpp
HEADERS += /
../../../framework/inc/myapp.h /
../../../framework/inc/mycontrol.h
INCLUDEPATH += ../../../framework/extlibs
Incluya este .pri en MyApp.pro como:
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)
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.
Yo uso este enfoque: http://xilexio.org/?p=125
A saber, coloque una configuración de test en el archivo .pro único que crea todo. Jerarquía de archivos:
myproject.pro
src/
Example1.cpp
Example2.cpp
Example1.h
Example2.h
test/
ExampleTest.cpp
ExampleTest.h
archivo 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)
}
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 sea necesario en virtud de la cláusula else , las bibliotecas de complementos no lo tienen. Si no se hace esto, la main() de la aplicación chocará con la main() de las pruebas de la unidad.
ExampleTest.cpp tiene el siguiente aspecto:
#include "ExampleTest.h"
void ExampleTest::exampleTest(){
//Do the tests
}
QTEST_MAIN(ExampleTest)
ExampleTest.h 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"