Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
[Solved] How to begin with using QtTest?
I came across QtTest accidentally. I have been developing an application & have been doing the QA manually.
But now I am unable to handle it as its size has grown. QtTest looks promising.
Can you please give me some suggestions as to how I should begin implementing it in my application?
Did you have a look at the "tutorials/manuals of QtTest":http://doc.qt.digia.com/solutions/4/qttestlib/qttestlib-manual.html? For every module/class/group of classes – how ever small you can break it down to maintain a functional unit – you write a number of functions that test the behaviour. You modify the internal state of the module and then check whether what you expected has happened, e.g. with QCOMPARE and QVERIFY.
GUI-tests are another thing on a higher level, i.e. not quite as fine-grained as backend tests, but more user-oriented (detects errors that users are likely to encounter, easier, i.e. with less code than a full coverage backend unit test). They work by simulating a user using the GUI – clicking buttons, entering texts – and then checking whether the application has done what was expected to happen.
If your project is large and has many interconnections, retro-fitting unit tests will be a pain. If you notice that you can't properly separate modules of the backend to make them testable, see it as a sign that they're too strongly coupled and need refactoring. The alternative, when the strong coupling is justifyable, is creating mock-objects.
Thanks for replying!
Yes I did read that document.
I am concerned about production build.
What do I do when I have to create the production build?
Because adding many tests (hundreds; which I will be requiring) will result in large size of target. Currently my exe is only 600 KB.
Plus it may create some bugs if not cleaned up properly.
The unit test code isn't inside application code, it uses classes of your application, to test them.
So in the same project as target executable, I can create a class which will handle all the tests. The testing can be done purely from this class & there is no need to add any code in other classes. Finally for production build I can simply delete the testing class.
Am I correct?
It might be doable like you describe, and I don't know how others do it. But In my project (which admittedly is a library and thus has no GUI, so it may not apply 100% to your case), the automatic unit test is a completely independent project (.pro file) in a different directory. It includes the library headers as necessary and instantiates classes as necessary for each testing routine. The testing itself is split up in different cpp files targeting different features of the library. The cpp files then contain a central test-class which has methods that test individual (public) interfaces of the library. It is true that this approach wouldn't work exactly the same if you want to also test private and protected methods. In this case you might have to do macro voodoo to declare the "private:" and "protected:" statements away in test runs.
Maybe someone else with application development/testing experience can give his view on unit tests including GUIs.
Thank You so much!
That was very helpful.
I will try to dig in to it now :)