Hello Everybody
Currently we create a lot of software-tests by using Code::Blocks together with UnitTest++, where a test is part of a new Code::Blocks project to create a binary. It is very convenient to create the test by using Code::Blocks. But in the end we have to connect every test with an external test- and requirement-manager tool that should be able to define a list of tests which should be repeated and to start them.
In our project we realise every small test-package (a couple of tests which should be used together) as a single build-target of a project. Thus we may save the cb-project file in our test data-base. Once a test should be done the the test-manager should start Code::Blocks to rebuild the associated build-target and start it. How can this be done ?
Best regards,
Eckard Klotz.
Quote from: eckard_klotz on October 19, 2012, 08:06:17 AM
Once a test should be done the the test-manager should start Code::Blocks to rebuild the associated build-target and start it. How can this be done ?
Well you can build projects with C::B from the command line, including to close C::B at the end. What you cannot do (atm) is
running a certain target of a project from the command line (not only because this may never return). But this you should do within your testmanager anyways, don't you?
Hello Morten.
Thanks or your quick reply. In the meanwhile I also found the corresponding chapter in the manual
1.12 CodeBlocks at the command line.
Here I found an example:
Quotecodeblocks.exe /na /nd --no-splash-screen --built <name>.cbp --target='Release'
I understand your answer together with the existing
target-argument that it is possible to build only one defined target defined in a project. But it will not be started even this is defined as post-build step. But as you mentioned this can be done by the test-manager also. More important is the possibility to have several build-targets in one project where only one can be chosen in the command-line.
So the process would be:
- 1. Use a c::b-project with several build-targets where one target contains only those tests associated with one requirement
- 2. The test-manager has to know which project file contains which target to test one requirement
- 3. The test-manager has to create a os-specific script-file to start C::B to build the desired targets (one target per command-line)
- 4. Once the targets are created, the test-manager has to use additional command-lines to start them
What do you think?
Best Regards,
Eckard.
Quote from: eckard_klotz on October 19, 2012, 12:05:50 PM
But it will not be started even this is defined as post-build step.
Pre-and post build steps are run trough. If you starting applications there, this will work. (I didn't think about that.)
What I meant is that there is nothing like a "
--run-target=Foo" command line switch. However, running applications in batch in a build process that may not terminate properly including as a post-build step will also not end the C::B batch build. Therefore it maybe risky to do such if you want everything be full automated. For such to work you'll need a "supervisory"/"monitor" process that would kill and shut down everything if i.e. the build is broken, or the running application hangs.
Quote from: eckard_klotz on October 19, 2012, 12:05:50 PM
So the process would be:
- 1. Use a c::b-project with several build-targets where one target contains only those tests associated with one requirement
- 2. The test-manager has to know which project file contains which target to test one requirement
- 3. The test-manager has to create a os-specific script-file to start C::B to build the desired targets (one target per command-line)
- 4. Once the targets are created, the test-manager has to use additional command-lines to start them
Point 4 is arguable (due to my explanation above), but basically: Yes.