[Unit Test Coverage] How can the industry improve QT code coverage
-
Hello everyone, I am a C++ QT application engineer in the industry.
After nearly 10 years of iteration, our products are facing the problem of lower and lower code unit test coverage. Low code unit test coverage is very detrimental to code quality and product quality.
So we have been looking for ways to improve QT code unit test coverage or some guiding principles.
I would like to ask the experts in the industry whether you can provide some experience to guide us to improve QT code unit test coverage?
Thank u if u can share us some ideas!
-
Hello everyone, I am a C++ QT application engineer in the industry.
After nearly 10 years of iteration, our products are facing the problem of lower and lower code unit test coverage. Low code unit test coverage is very detrimental to code quality and product quality.
So we have been looking for ways to improve QT code unit test coverage or some guiding principles.
I would like to ask the experts in the industry whether you can provide some experience to guide us to improve QT code unit test coverage?
Thank u if u can share us some ideas!
@xurongqin Not clear to me: do you want to test Qt code or the code of your application?
-
@jsulm , Thanks for your kind reply, I want to test the code of my application. My purpose is want to know how QT developers improve the unit test coverage on their application. Are there any rules or unit test frameworks that can help to guide us to improve the unit test coverage?
Thank you so much
-
Hi and welcome to devnet,
For testing frameworks, Qt already provides the QTest module which works pretty nicely.
As for the rules, there's mainly one: test both happy and unhappy code paths. That way you ensure that your code is working when everything goes well as well as when issue arise.
-
Hi @SGaist , Thanks so much for your reply. You advice seems interesting and is useful for us.
Now we have a complete QTest framework in out QT application. But R&D found it was hard to write the UT since they sometimes felt that it was not smooth enough to cover all of the classes. The root cause might be from bad code design or something else. After we analyzed out QT application, we found that refactor the code by the MVC (Model-Viewer-Controller) design to decouple the classes might be also a possible way to help the R&D to write the unit test coding since some classes did not well follow the MVC design.
If you have more detailed idea on it, pls share more information with us.
-
Hi @SGaist , Thanks so much for your reply. You advice seems interesting and is useful for us.
Now we have a complete QTest framework in out QT application. But R&D found it was hard to write the UT since they sometimes felt that it was not smooth enough to cover all of the classes. The root cause might be from bad code design or something else. After we analyzed out QT application, we found that refactor the code by the MVC (Model-Viewer-Controller) design to decouple the classes might be also a possible way to help the R&D to write the unit test coding since some classes did not well follow the MVC design.
If you have more detailed idea on it, pls share more information with us.
@xurongqin said in [Unit Test Coverage] How can the industry improve QT code coverage:
pls share more information with us
What exactly do you need?
MVC with Qt is documented here: https://doc.qt.io/qt-6/model-view-programming.html -
Hi @SGaist , Thanks so much for your reply. You advice seems interesting and is useful for us.
Now we have a complete QTest framework in out QT application. But R&D found it was hard to write the UT since they sometimes felt that it was not smooth enough to cover all of the classes. The root cause might be from bad code design or something else. After we analyzed out QT application, we found that refactor the code by the MVC (Model-Viewer-Controller) design to decouple the classes might be also a possible way to help the R&D to write the unit test coding since some classes did not well follow the MVC design.
If you have more detailed idea on it, pls share more information with us.
@xurongqin It is really useful if the model is entirely separate from the view and controller. The model holds the data and acts on the data. Every functionality could just be tested on the model, no viewer or controller needed. Testing the view and controller would then just mean to test if the GUI triggers the appropriate actions inside the model (you might even just mock the model to check if the correct functions are called, already knowing from testing the model that it works). I'm not sure if testing the view appart from the controller makes sense. The view should just show things and the controller actually connects the view to the model (i.e. allows the GUI to trigger actions). A lot of times, with Qt view and controller are not necessarily separate anyway (I write constructors that create widgets, puts them inside a layout and then does the connects–this would be mixing the view (widgets+layouts) with the controller (connects)).
-
Best strategy is to design your application from the get go to be testable.
When designing Every class, every module, every component you should think "how do I make this testable". The good news when you make things "testable" you also get other "abilities" for free since highly testable components are also a) independent and decoupled b) have high cohesion and simple dependencies c) reusable d) have a coherent API c) have better thought out errors and bug conditions, invariants and pre/post conditions.
Then you test your components using whatever (unit) testing framework you like.
For UI testing you can also use some UI testing tools such as cucumber or other similar tools
