4

I am using QTest of Qt 5.3.2 to execute some unit tests on a class. I am using VS2013 Express to build the tester. The VS project file is generated from a .pro file using qmake. For running the tests I added the QTEST_MAIN to my source file.

The project builds and the tester executeable work fine. However I have problems seeing the results (e.g. PASS output). While the test is running a console window opens receiving all the testing output. If the test is finished the console window closes immediately and I can't actually see what it displayed. Especially I can not see if some tests failed.

I suppose QTest uses stdout as default output channel. So I tried the VS debugger option "Redirect stdout to output window" but it had no effect.

So how is this supposed to work?

Should the testing output actually go to a newly opened console window? Then why isn't it kept open? Or should the entire testing output go to the VS debugger output panel? Is there a way to redirect the output?

Silicomancer
  • 8,604
  • 10
  • 63
  • 130
  • Why do not you simply run your test (application) from the console (command line)? Leave VisualStudio alone. – vahancho Oct 12 '14 at 15:04
  • Because it is much easier to debug the tested code and to improve the tests when using the VS IDE. I mean that is what an IDE is made for. There must be a simple solution I suppose. – Silicomancer Oct 12 '14 at 15:07

1 Answers1

4

Do you have the Visual Studio Add-in installed for your version of Visual Studio? If not you should download it from qt-project.org/downloads.

I did a simple qt test and imported the *.pro file inside Visual Studio and ran the test; for me everything works fine and the window stays open showing the resume of the tests:

enter image description here

What I recommend is writing the example, importing it in Visual Studio using the Visual Studio Add-in and compare the project settings. Chances are a flag needs to be changed somewhere in order for the window to stay opened.

It also could be that you need Console (/SUBSYSTEM:CONSOLE) linker option set. Right click on the project, go to the project Properties, choose Configuration Properties>Linker>System. For the Subsystem property in the right-hand pane, click the drop-down box in the right hand column. Now choose Console (/SUBSYSTEM:CONSOLE) and reran the test(Ctrl+F5 and NOT just F5)(1).

If you run the test in Debug mode (i.e. pressing F5) your window won't stay open. If you want it to stay open you need to add a getch() call in your test destructor, and when your test finishes the window will stay up waiting for input(e.g. Enter):

For my test code would be:

#include <QtTest/QtTest>
#include <conio.h>

class TestQString: public QObject
{
    Q_OBJECT
private slots:
    void toUpper();

public:
    ~TestQString()
    {
        getch();
    }
};

void TestQString::toUpper()
{
    QString str = "Hello";
    QCOMPARE(str.toUpper(), QString("HELLO"));
}

QTEST_MAIN(TestQString)
#include "testqstring.moc"

(1) - How to keep the console window open in Visual C++?

Community
  • 1
  • 1
Iuliu
  • 4,001
  • 19
  • 31
  • No, I can't see the results there. But what do you mean with "export"? – Silicomancer Oct 12 '14 at 14:25
  • @Silicomancer By export I meant what you said about redirecting(I tried the VS debugger option "Redirect stdout to output window"). But please see my edits. – Iuliu Oct 12 '14 at 15:37
  • Currently I am using the Express version of VS 2013. This means I can not install plugins :-( – Silicomancer Oct 12 '14 at 15:43
  • I check the console option. It is already configured as you proposed. Anway when running with Strg+F5 the window stays open. That's pretty weird. Seems I need to code my own main function including a waiting call :-( – Silicomancer Oct 12 '14 at 16:01
  • `when running with Strg+F5 the window stays open` - isn't this what you want? Why do you need to write your own function, then? – Iuliu Oct 12 '14 at 16:04
  • Not exactly what I had in mind. I would like to use the debugger the same way. On the other hand when using the debugger I can easily set a breakpoint instead. So you are probably right that this is a sufficient solution. – Silicomancer Oct 12 '14 at 16:08
  • It works perfectly now. I used the following code in the destructor: if (IsDebuggerPresent()) { cout << "Press a key to continue..."; getchar(); } – Silicomancer Oct 12 '14 at 16:24