User forums > Announcements
Unit testing in Code::Blocks
killerbot:
--- Quote from: jimp on October 01, 2009, 11:39:15 pm ---Great job on the article. I have three questions.
In LeapYear-Step2 you said "it is good to put the tests in a nameless namespace (will be explained later on)". But you never explained it. Why is this a good idea?
--- End quote ---
My mistake, I will add this. Basically if you have 1 unit test project for a component, then you will be testing several classes, 1 test file per class.
Then you might have several :
Test(Constructor)
tests.
And if they are in each test file in a anonymous namespace, there will be no conflicts at linking time.
--- Quote from: jimp on October 01, 2009, 11:39:15 pm ---What if you have a console program that has a main() function. This will conflict with the main() function in the test program used to call the unit tests. What are some ways to resolve this? (The ideal solution would be one that doesn't require modifying the original source.)
--- End quote ---
I think it is best to have a dedicated project for the unit test(s), since it is intended to test units. When you have another main(), the main of the application, then the application might be to big to be a unit. The application itself can be tested. Unit tests focus on testing the building blocks, the smaller units.
--- Quote from: jimp on October 01, 2009, 11:39:15 pm ---Do you plan on automating the UnitTest++ program in CodeBlocks? For instance a template that will generate the "main" test source and possibly a test source for each source or class in a project file. It could also link to the UnitTest++ library and compile the library file if needed. UnitTest++ also has the capability of GUI output. The test run can be activated from a toolbar, displayed in a GUI, and clicking on an error line can then display the source and indicate the line with the error (the CodeLite IDE has this capability). It would be a useful addition to CodeBocks.
--- End quote ---
Good ideas, on my long term to-do list.
--- Quote from: steve on September 10, 2009, 11:50:16 am ---I use googletest (http://code.google.com/p/googletest/), another great framework for unit testing. The latest version of googletest, from the head of the repository, can be easily built with MinGW and Code::Blocks.
It would be nice if you could "generify" your article by separating out the UnitTest++ specific bits, and possibly indicating which parts of the project files would need to change if you want to use a different unit test framework.
--- End quote ---
As a first step I will do the article again, but then for the google-test. Thanks for pointing out google-test to me. I didn't know it.
In the mean time I already have done the first experiments, leading to a cbp file for it ;-)
Lefteris:
Hello!
This was a very nice guide, I wanted to practice unit testing for a long time now in a structured and automated manner and this tutorial seems to be a very nice pointer to that direction.
But I happen to have a question. You say that we should have a separate project dedicated to unit testing, right? If our application is say..a big GUI project with different modules.. we would include the source of the main project from the unit-testing project and run all our tests, right? Is there anyway to make the tests run at building the main project and not the testing project?
In other words can we build the testing project (thus in effect performing all the tests again) every time we want to compile the main project?
Thanks again for witting the guide :)
killerbot:
There are several possible things to achieve your goal.
A first reflex of mine would be :
* GU app with several modules
* write unit tests for those modules (set of unit tests of the classes of those modules)
* when the app is build, we want a post build step that build all the unit tests too, and run them
** this can be done by creating a workspace, that consists out of the project file for the GUI app, and the project files of the unit tests. In CB you just choose to build the workspace (this can also be done by inoking CB on the command line, that way you can nicely incorporate it in a nightly build system)
** you could invoke as a post build step of the GUI app, to build the unit tests (which in their post build step will run), not sure exactly how to do this (calling CB again with command line parameters will do it), but I prefer the workspace approach.
Hope these from the top of my head ideas can but you on the right track ;-)
lexis:
Hello all.
It is good deal to describe how to utilize a common possibility for a particular purpose.
I am doing TDD in the same way too but with CxxTest. It requires an additional pre-build step to generate a cpp file from test definition in header.
But as I say above it is common tool: use pre/post build steps.
It would be really nice to have special Unit Test project type and wizard. It would provide developer with close integration of unit testing framework with CB like per test mapping to project targets for an example.
oBFusCATed:
You can make your own wizard (see the source of existing wizards) and then share it with us :)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version