CODEWITHSUNDEEP
c++qtqt4build-process
snoofkin
snoofkin

Reputation: 8895

Testing Process of a C++ & Qt Application

I'm a part of a big (sort of...) C++ application written mainly in Qt. I was wondering if this is the right / common approach: whenever I make a change to a certain / several source files, I compile it (QtCreator) in debug mode, and then launch and test it. the problem is, each compilation takes a couple of minutes (usually a 1 - 3 minutes), I hate that, and I guess I'm doing something wrong here, maybe compiling the whole project for each minor change is not the right path to go?

thanks,

Upvotes: 1

Views: 420

Answers (4)

pedromateo
pedromateo

Reputation: 3115

Also answered in: Qt automated testing

I along with my team recently developed TUG, an open-source framework for Qt GUIs Unit Testing. Is uses Qt Test. Maybe it can help you.

A video better than a thousand words: https://www.youtube.com/watch?v=tUis6JrycrA

Hope we can make it better together. Github repo: http://pedromateo.github.io/tug_qt_unit_testing_fw/

Upvotes: 0

Johan
Johan

Reputation: 20763

Try to use unit test with QTest as much as possible, then you can verify the parts first and then top it of with some test on the complete application. This saves a lot of time and can also help to produce more robust code if done right.

This do need some kind of modular approach, so the code needs to be grouped in some way.

Upvotes: 1

rasjani
rasjani

Reputation: 7970

Do you have multiple SUBDIRS targets within your project ? If the answer is yes, You could try tweaking the project file by first removing all "ordered" keywords from project files and then if one subdir is depending on another, declare those as dependencies. And finally, make sure you pass -jX value to make (that is, if your build rules use make) so that all cpu cores are taken into use while compiling.

Upvotes: 0

AJG85
AJG85

Reputation: 16187

Most likely you need to tweak your build settings to ensure you are doing minimal rebuild or incremental build where it only compiles the files that have changed and doesn't update or rebuild anything not directly affected by the changes. This still doesn't help when you are changing a header file that's included heavily throughout the project but with a well laid out project that shouldn't happen.

In general there are several approaches to testing as you go but here are the main two things I'd recommend:

  1. Don't rebuild the entire project (no clean, no rebuid all) just do an incremental build and test as you go. Great for testing gui changes and little things in projects that don't need to link against a million things or have a long start up.
  2. Develop it as separate project with a console app or simple test application which you don't include in the final integrated version but can keep for independent testing later. This is better for libraries like say you are making a new encryption algorithm or file manager to replace some old archaic portion of a bigger project.

Of course there is always the approach of coding with overwhelming confidence like a crazy person and crossing your fingers when you compile and run it which is very popular but not quite as effective.

Upvotes: 1

Related Questions