Some thoughts on a unit testing plugin

[Kazade]

After using Netbeans and Eclipse for my job, I've found one of the things which is missing from Code::Blocks (aside from refactoring tools) is the ability to create, edit and run unit tests (using boost::unit, cppunit, cxxtest etc.) and have it all nicely integrated into the IDE.

So this morning (after my first venture into plugin writing yesterday) I began thinking about how this kind of integration could be achieved. Ideally, "Tests" would show up along side "Sources" and "Headers" in the project tree. Each source file would itself be it's own sub-project (it compiles to an executable). Right clicking the "Tests" folder should give you a "Run all tests" option which would run the project's tests and report the results in a nicely colour tab in the Messages pane (green for passes, red for fails). Each test should be compilable and runnable like any other project. There should be a File->new->test option and the ability to mark an existing source file as a test (I'm thinking Right click->Mark as unit test).

Now here's my question, how much of this is possible with the plugin API? I don't think the concept of sub-projects (multiple executables inside a project) exists, am I right? If I wrote patches for this kind of feature would they be accepted?

This kind of integration would be a killer feature for a C++ IDE, I've recently seen the light when it comes to unit tests and I'd love to be able to add the quickly and easily like this. I don't mind doing the work to write the plugin, but I'm trying to gauge how difficult it will be.

[dje]

Hi,

I don't think the concept of sub-projects (multiple executables inside a project) exists, am I right?

Have a look at the target concept in C::B. In a workspace, you have projects. In a projects, you have targets (libs, exes...)

Dje

[killerbot]

what I do : use unittest++, and in release build the unit test is run as a post build step, and when a test fails, it jumps to the offending line. Since it is a post job it's output shows up in the compiler pane.

So it's not optimal yet, no green and red bars, but when all tests succeeds the build reaches the end, otherwise it is just like a compile error. So you can include them in a nightly build system or in continuous integration ystems.

[Kazade]

OK I've been thinking that if I was to write this plugin this would be the way to go (thinking aloud here, please tell me if I'm barking up the wrong tree)...

1. When the plugin is loaded (and indeed a project created or loaded) a virtual folder called Tests is added (if it doesn't exist)
2. Adding a test creates a new build target with a single file (the test source). The test source is added to the virtual folder
3. Removing a test source will remove its associated build target, likewise, removing the build target removes the source file
4. There will be a virtual build target called something like "All Tests", which contains all the test build targets

I might have misunderstood how, build targets and virtual folders work. I haven't thought about how the output of the test runs will work, but just getting this bit working would make my life easier

Now... my questions:

1. Can I alter the context menu that appears when right clicking the virtual folder, or sources within the virtual folder using the SDK?
2. Is there anyway to add a new build target type? (it would help to differentiate what is a test build target, and what isn't)

P.S Killerbot: Thanks I'll give that a go later