On Tuesday 14 June 2011 09:32:52 joerg [..] ... wrote:
> Hi all,
>
> is there a way to do unit testing for components using boots test??
>
> >From what I understood so far boost test supplies an application start up
> >and requires a main function from the application under test. However,
> >orocos does some startup stuff too before ORO_main is called.
>
> Is there a way to bring this together??

We have discussed this some time ago on the list, but no action was given to
it. I believe that the component testing is done by a script which uses a
service that provides operations that translate to a C++ unit testing library.
You can use rttlua or rtt scripting for this.

It seems mailman archives are down and the follow-up did not appear on the
website forum, so here is a verbatim copy of my answer:

<quote>
The way I would unit test a component is by exercising its operations and
ports in a script. We could build a unit test component, similar to a logging
component, that provides the unit testing API the script needs.

The script could then look like:

(loaded in a deployer):

// create components and ports
program SetupTest {
  import("unit") // loads the unit test component library
  loadComponent("unit","unit") // creates the component
  // OR loads it as a service:
  loadService("unit","unit")
 
  import("myapp") // loads the component library to test
  loadComponent("bob","myapp::FooBar") // creates one instance of FooBar
 
  unit.newOutputPort("A","myapp.FooBarStruct")
}
 
// this program could be loaded in 'unit' too (or unit is a service in the 
deployer):
program TestSomeFeature {
   bob.parameter="baz"
   unit.Require( bob.isRunning() ) // we could also quote the arg-"bob.isR..."
 
   connectTwoPorts("unit","A","bob","B")
   unit.A.write( myapp.FooBarStruct ) // write the port
   unit.CheckMessage( bob.receiveCount() == 1, "myapp::FooBar did not receive 
message")
   // ...
}

The proposed 2.2 scripting improvements of last week would help in this
scenario too, where SetupTest would be the leading statements before
TestSomeFeature, instead of a separate program and the file could end with the
statement TestSomeFeture.start()
<endquote>

In 2.4, we no longer need to put tests in 'program' sections, you can just
write them up in a single file.

Peter

2011/6/14 <joerg [..] ...>

> Hi all,
>
> is there a way to do unit testing for components using boots test??
>
> >From what I understood so far boost test supplies an application start up
> and requires a main function from the application under test. However,
> orocos does some startup stuff too before ORO_main is called.
>
> Is there a way to bring this together??
>

I personnaly didn't succeed in this (thought not involving many time to it),
but maybeyou could find some hints in the unit tests of Orocos. At this time
I tried to redefine ORO_main to have my personnal ORO_main function with
required hooks, but I think this is too hacky.

What is maybe also possible, is to create port in your tests (outside of any
component) and connect them to a deployed component (you may need Mqueue
transport there because you have 2 distinct process...). Is it maybe
possible to create a TestTaskContext that will initialize boost in his
configureHook or so on, but I am not sure it is possible.

If you really seperate your bussiness logic (in a library for instance) from
the glue code to put this logic into Orocos you should be abble to unit test
your bussiness logic independantly and then only have "functionnal tests" to
do in Orocos. For this functionnal testing, a TestTaskContext that you can
connect like you whant in a pre-existing deployment would be great ! But
doesn't exists yet :( (I think it is a welcome contribution).

In recent discussion there where a proposition to transform ORO_main in a QT
like function, it could also solve this kind of problem, letting the user do
his main as he want.

>
> Ciao
> Joerg
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>