I'm trying to unit-testing my Qt application with QTestLib. I saw that the new Visual Studio 2012 has a built-in C++ test framework and googling for it I saw this page that talks about different methods to test a native project. I would have two different projects, one for the normal program and one for the tests. Actually my application is not a DLL but it's a simple C++ exe. Is the best way to test it with another project to link against .obj files or against libs? I wouldn't export anything from the source code as mine is not a DLL
-
Assuming you are using qmake as build tool. Re-using object files will make it difficult to perform stubbing, as you have to mix original object file for the tested unit with object files for stubs. To make it possible you would need to have all object files in separate directories, i. e., every unit per directory. Other approaches would be producing set of static libraries and re-using them in tests. And just simply including source code in the test, it will be compiled and linked twice. – divanov Aug 27 '12 at 07:40
-
my application is an EXE, how could I build it as a static library? However I'm using Visual Studio but I plan to support multiple platforms, so the tests in the future should run also on Linux – Stefano Aug 27 '12 at 09:14
-
As long as you have separate units in your architecture, you can split them as independent libraries. For example, any custom widget or set of widgets can be a separate library. Then you will have a main unit, which will glue all other units together and link with libraries representing them. – divanov Sep 03 '12 at 09:24
1 Answers
This is a typical QtTest project with three code units: unit1, unit2 and unit3
project/
├── project.pro
├── src
│ ├── main.cpp
│ ├── src.pro
│ ├── unit1.cpp
│ ├── unit1.h
│ ├── unit2.cpp
│ ├── unit2.h
│ ├── unit3.cpp
│ └── unit3.h
└── tests
├── stubs
│ ├── stubs.pro
│ ├── unit1_stub.cpp
│ ├── unit2_stub.cpp
│ └── unit3_stub.cpp
├── test1
│ ├── test1.cpp
│ ├── test1.h
│ └── test1.pro
├── test2
│ ├── test2.cpp
│ ├── test2.h
│ └── test2.pro
├── test3
│ ├── test3.cpp
│ ├── test3.h
│ └── test3.pro
└── tests.pro
This project results in 4 binaries: 1 application itself and three test binaries for testing each of the units. For example, test1 should include src/unit1.cpp, src/unit1.h and also stubbed unit2 and unit3: src/unit2.h, tests/stubs/unit2_stub.cpp, src/unit2.h, tests/stubs/unit3_stub.cpp. With this kind of setup src/unit1.cpp and tests/stubs/unit1_tests.cpp will be compiled twice and this number will grow, if number of units will be larger. This is not a problem for small projects, but for huge projects this may lead to significant increase of build time.
Then splitting unitX.cpp and unitX.h into separate libraries with static linking to main application and each of the tests will eliminate need for building multiple times.

- 6,173
- 3
- 32
- 51
-
Thank you for the explanation, I was trying to use QtTestLib but it seems that it hasn't extensions points and so I can't integrate it with TeamCity realtime tests log. Also it appears to use an old xunit XML format to output the log file. I think I will stick with google test also if I'm not happy to use something not really integrated with Qt – Stefano Sep 03 '12 at 10:32
-
I've just quickly found that TeamCity can read XML tests report with XML Report Plugin. And QtTest will produce XML output, if -xml option is given, on the contrary, -xunitxml will result in xunit output. – divanov Sep 03 '12 at 11:08
-
I know that it can read the XML but I would like to have real-time reports and not post-build tests results. Also it seems that QtTestLib is using an old format and I'm not sure it is fully xunit compatible – Stefano Sep 03 '12 at 11:12
-
1You want to use the -xml option for xunit compatibility. See http://stackoverflow.com/questions/13339513/showing-the-result-of-qtestlib-with-jenkins-xunit-plug-in – Leif Gruenwoldt Dec 19 '13 at 20:41