QtTest - Share your workflow

[uod_]

Hi, I would like to see other developers' workflow and settings when using QtTest. Please, try to explain your reasoning as well if you think it can help others.

1. How do you structure your project? (Folder structure, Qmake, CMake settings, etc)

2. What are you testing? (Do you test Qt modules, elements, your own libraries, 3rd party libraries, only unit testing or testing high-level GUI functions, etc ..)

3. How do you deal with other interfaces? (Local database, remote server, hardware, mock hardware, etc)

4. What do you put in constructor, destructor, init(), cleanup(), initTestCase(), and cleanUpTestCase()?
   (ex: "I open database then create tables at init()", "I use setApplicationName("myApp") within constructor" ...)

5. Besides general good testing practices, is there any framework, or tips, you follow?

6. Is there any Qt-specific testing tips you have for other developers?

Thanks for your time in advance.

edit: miswriting

[SGaist]

Hi and welcome to devnet,

Your post sounds almost like a survey. Is it one ?

[uod_]

Hey, thanks a lot.

I didn't mean it to be a survey, I wanted to copy the good practices of other developers who are more experienced with Qt. The Internet has many resources to be used as guidelines when it comes to testing, but I wanted to see more concrete examples. While working with Qt I figured I should tailor my unit tests to utilize Qt when I can. This is why I wanted to ask people about their experiences.

[SGaist]

You can pick up ideas from the Qt source tree itself.

That said one possible nice architecture:

• use sub-projects
  • one or more libraries for your business and widget logic
  • each is again a sub-project based project where you have all the required tests in a dedicated folder (which is again based on the sub-project template)
  • one application project that puts together the core widgets of your application. Basically this project is usually just a ˋmain.cpp` file that loads your main widget and do some initialization stuff if needed.

So all your tests are close to the code they are ensuring works correctly.

You can have tests at various levels to ensure that you library code is doing what is expected, then upper that the code using these libraries are also working as expected etc.

Don't do low-level tests at a higher level. For example, testing that a widget acts correctly to answers from a device on a serial port does mean that you have to run these tests for every possible configurations of the serial port.

The example above is also a good candidate for mocking. When testing, you typically don't have a device at hand connected to your CI (it might possible but not always) hence the importance of writing your code so that you can replace the serial device with a "virtual device" for your tests. Typically, rather than have an internal QSerialPort, you should have the controller class that accepts a configured QIODevice and use it's interface, that way, when testing you can pass a mock device.

[uod_]

@SGaist Thank you for taking the time. Now, I am happy that I've more or less applied the architecture and workflow suggested by the man himself already. The example you used toward the end is exactly my case, which leads me to ask for tips here.

I will be checking the source tree for more specific cases and will be making modifications accordingly.