Project Structure for Projects in Qt Creator with Unit Tests


For this post I will be proposing a project structure in Qt Creator that allows you to have your unit tests project with your main project.


If you think this post looks familiar, you have probably gone through a similar post from Svenn-Arne Dragly. This project is actually a simpler fork of his, so credits to him.

Why fork out from Dragly’s project structure? (you can skip to the next part if you want.)

I had to build out a library file – this is a bit of a hassle to me. In addition the example in github ( didn’t work either:

LNK1104: cannot open file 'myapp.lib'.

It’s because I’m using the MSVC2013 compiler and it only builds out a *.dll and forgot a *.lib. Turns out I have to add __declspec( dllexport ) as so:

class MyClass {
     __declspec( dllexport )  double addition(double a, double b);

Even so it still asks for the *.lib file, despite it already being built. I had to explicitly add the path to the external library, and then place the compiled *.dll in the same directory as the executable. I guess, if I specify a common build directory and have it look for the lib file there it would work… but think about this: __declspec( dllexport ) is microsoft specific. If I run the same code in linux it spits out an error. I could use some macros to check for what compiler is being used, but it’s a hassle (to me, at least).

So if you only intend to develop using a particular compiler that’s fine. I just figured I wanted something more straightforward.

Project Structure

The approach I came up with involves compiling some/most of your code twice, but it was what I stick to in the end for a test project I was working on (Click here to download an empty template) :

Project Directory:
 ├───app -> source code
 │       AbstractGroup.hpp
 │       ActiveSelection.cpp
 │       ActiveSelection.hpp
 │       Canvas.cpp
 |       ...
 ├───build -> build directory
 │       DrawingApp.exe
 ├───lib -> libraries
 │       catch.hpp
 └───tests -> test project, which you only add files from the 'app' folder that you want to test
         TestMain.cpp -> DO NOT call this main.cpp! It will clash with your main.cpp in the 'app' folder, even though they are in separate directories.

You can see a real life example in my github project: – I will be referring to this project so do keep a tab open.

It will look something like this in Qt creator:

2015-05-30 14_13_55-defaults.pri - MyProject - Qt Creator

This might be a hassle for some, because you would have to add the source files into the unit test project every time you created a new class. Otherwise the unit test project will fail to build and you’d likely confuse it to your actual project not building.

But that was just because I wasn’t really doing TDD. I created the source files before I write the unit tests. Well, it’s a drawing app; I can’t unit test drawing capabilities right?

Loose Coupling, Tight Coupling

After initial frustrations of using this structure, I realized doing it this way does disciplines a programmer to think about coupling. After a while it had me asked questions like “If I just want to test object A, should I need to also depend on object B and C? Can object A be isolated and used separately?”.

Great software design meant loose coupling; only when necessary should objects be bundled together. Otherwise they should be able to be packaged, isolated, reused, and unit tested separately.

This is why the file contains significantly less files compared to

Calling headers in different directories

Notice, that for example in the DrawingApp project, that a fileio/JsonFileReader.hpp is able to call interfaces/IFileReader.hpp by just

#include "IFileReader.hpp"

This isn’t default behaviour as in codeblocks, I had to manually configure this in the project file for both and

 $$PWD \
 interfaces \
 commands \
 tools \
 shapes \

Tedious maybe, but a small inconvenience to me. I wasn’t sure if Qt Creator has a setting to make this default behaviour, but this is what I can come up with.

A Note on Catch

This single header unit test framework is too easy and convenient not to use. The TestMain.cpp simply needs to contain


#include "catch.hpp"

and then you can start adding separate test *.cpp files for each class (or however you want to structure your tests).

If you haven’t tried it out I highly recommend you do.


Think there can be a better way? I’m open to ideas.

You can download an empty template project from here: Click here to download an empty template.



Auto-formatting source code using AStyle

Today I talk about how to get AStyle 2.04 the awesome code beautifier working with Qt Creator 3.1, and towards the end share my configuration settings (C++).


I have a particularly strange habit to code: I can’t stand it if it doesn’t look pretty. I make a fuss about formatting, on whether code is readable and properly formatted by consistent and standard code conventions. In short, messy code is disgusting to me.

I doubt I’m the only one like this (:

For awhile now I’ve been manually formatting the code, little seemingly insignificant stuff point of adding spaces between operators and removing spaces around parenthesis, until I realize how it was actually kinda unproductive.

Enter AStyle

I setup Qt Creator via this link. Apparently Qt Creator 3.1 already has beautifier just setting around, but disabled for some reason. You then need to download AStyle and set the exe accordingly.

Then… after that I started wandering around the web wondering where to get a predefined set of formatting options for it. It was actually quite hard to find what I was looking for, truth be told. In the end I just look up the documentation and make it work for me. It wasn’t too bad; was actually kinda fun seeing the code just fixed up itself.

So here is my self-defined style (C++):


My only gripe was that the only way to format the code I have to go through the menu:

Tools > Beautifier > Artistic Style > Format Current File.

I mean, I wanted to format a dozen files at once. Couldn’t there be a faster way? I can’t assign a keyboard shortcut to this command.

…but I’m glad nonetheless 😀