On 10/17/2010 09:42 PM, Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that
> there is Orocos Tests, I wonder if it exists any documentation or main
> classes that I could use directly from rtt in my project. If none I
> will read rtt code, but If I could avoid to read this from scratch it
> would save my time :)
>
>
In the dfki toolchain, we use Ruby to read log files or generate
synthetic data and feed that to the components. We then check the
component's outputs either automatically in simple cases or through
plots for more complex ones.
--

Sylvain Joyeux
Space& Security Robotics

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 218-64136
Fax: +49 (0)421 218-64150
E-Mail: robotik [..] ...

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

On Sunday 17 October 2010 21:42:49 Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that there is
> Orocos Tests, I wonder if it exists any documentation or main classes that
> I could use directly from rtt in my project. If none I will read rtt code,
> but If I could avoid to read this from scratch it would save my time :)

The only way we unit test our components in RTT is by creating 'mock-up'
components, ie use some functionality with 'fake' functions, which only toggle
a flag or so. The unit test then checks if the flag was toggled after using the
functionality.

So this is hardly what you need for unit testing an application component. 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()

I actually like this idea very much. Anyone ?(*)

Peter

(*) Or this is a perfect case to promote the lua scripting, ie to write unit
tests in lua.

On 10/17/2010 09:42 PM, Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that
> there is Orocos Tests, I wonder if it exists any documentation or main
> classes that I could use directly from rtt in my project. If none I
> will read rtt code, but If I could avoid to read this from scratch it
> would save my time :)
>
>
In the dfki toolchain, we use Ruby to read log files or generate
synthetic data and feed that to the components. We then check the
component's outputs either automatically in simple cases or through
plots for more complex ones.
--

Sylvain Joyeux
Space& Security Robotics

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 218-64136
Fax: +49 (0)421 218-64150
E-Mail: robotik [..] ...

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

On Sunday 17 October 2010 21:42:49 Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that there is
> Orocos Tests, I wonder if it exists any documentation or main classes that
> I could use directly from rtt in my project. If none I will read rtt code,
> but If I could avoid to read this from scratch it would save my time :)

The only way we unit test our components in RTT is by creating 'mock-up'
components, ie use some functionality with 'fake' functions, which only toggle
a flag or so. The unit test then checks if the flag was toggled after using the
functionality.

So this is hardly what you need for unit testing an application component. 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()

I actually like this idea very much. Anyone ?(*)

Peter

(*) Or this is a perfect case to promote the lua scripting, ie to write unit
tests in lua.

On 10/17/2010 09:42 PM, Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that
> there is Orocos Tests, I wonder if it exists any documentation or main
> classes that I could use directly from rtt in my project. If none I
> will read rtt code, but If I could avoid to read this from scratch it
> would save my time :)
>
>
In the dfki toolchain, we use Ruby to read log files or generate
synthetic data and feed that to the components. We then check the
component's outputs either automatically in simple cases or through
plots for more complex ones.
--

Sylvain Joyeux
Space& Security Robotics

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 218-64136
Fax: +49 (0)421 218-64150
E-Mail: robotik [..] ...

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

On Sunday 17 October 2010 21:42:49 Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that there is
> Orocos Tests, I wonder if it exists any documentation or main classes that
> I could use directly from rtt in my project. If none I will read rtt code,
> but If I could avoid to read this from scratch it would save my time :)

The only way we unit test our components in RTT is by creating 'mock-up'
components, ie use some functionality with 'fake' functions, which only toggle
a flag or so. The unit test then checks if the flag was toggled after using the
functionality.

So this is hardly what you need for unit testing an application component. 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()

I actually like this idea very much. Anyone ?(*)

Peter

(*) Or this is a perfect case to promote the lua scripting, ie to write unit
tests in lua.

On 10/17/2010 09:42 PM, Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that
> there is Orocos Tests, I wonder if it exists any documentation or main
> classes that I could use directly from rtt in my project. If none I
> will read rtt code, but If I could avoid to read this from scratch it
> would save my time :)
>
>
In the dfki toolchain, we use Ruby to read log files or generate
synthetic data and feed that to the components. We then check the
component's outputs either automatically in simple cases or through
plots for more complex ones.
--

Sylvain Joyeux
Space& Security Robotics

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 218-64136
Fax: +49 (0)421 218-64150
E-Mail: robotik [..] ...

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

On Sunday 17 October 2010 21:42:49 Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that there is
> Orocos Tests, I wonder if it exists any documentation or main classes that
> I could use directly from rtt in my project. If none I will read rtt code,
> but If I could avoid to read this from scratch it would save my time :)

The only way we unit test our components in RTT is by creating 'mock-up'
components, ie use some functionality with 'fake' functions, which only toggle
a flag or so. The unit test then checks if the flag was toggled after using the
functionality.

So this is hardly what you need for unit testing an application component. 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()

I actually like this idea very much. Anyone ?(*)

Peter

(*) Or this is a perfect case to promote the lua scripting, ie to write unit
tests in lua.

On 10/17/2010 09:42 PM, Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that
> there is Orocos Tests, I wonder if it exists any documentation or main
> classes that I could use directly from rtt in my project. If none I
> will read rtt code, but If I could avoid to read this from scratch it
> would save my time :)
>
>
In the dfki toolchain, we use Ruby to read log files or generate
synthetic data and feed that to the components. We then check the
component's outputs either automatically in simple cases or through
plots for more complex ones.
--

Sylvain Joyeux
Space& Security Robotics

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 218-64136
Fax: +49 (0)421 218-64150
E-Mail: robotik [..] ...

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

On Sunday 17 October 2010 21:42:49 Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that there is
> Orocos Tests, I wonder if it exists any documentation or main classes that
> I could use directly from rtt in my project. If none I will read rtt code,
> but If I could avoid to read this from scratch it would save my time :)

The only way we unit test our components in RTT is by creating 'mock-up'
components, ie use some functionality with 'fake' functions, which only toggle
a flag or so. The unit test then checks if the flag was toggled after using the
functionality.

So this is hardly what you need for unit testing an application component. 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()

I actually like this idea very much. Anyone ?(*)

Peter

(*) Or this is a perfect case to promote the lua scripting, ie to write unit
tests in lua.

On 10/17/2010 09:42 PM, Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that
> there is Orocos Tests, I wonder if it exists any documentation or main
> classes that I could use directly from rtt in my project. If none I
> will read rtt code, but If I could avoid to read this from scratch it
> would save my time :)
>
>
In the dfki toolchain, we use Ruby to read log files or generate
synthetic data and feed that to the components. We then check the
component's outputs either automatically in simple cases or through
plots for more complex ones.
--

Sylvain Joyeux
Space& Security Robotics

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 218-64136
Fax: +49 (0)421 218-64150
E-Mail: robotik [..] ...

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

On Sunday 17 October 2010 21:42:49 Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that there is
> Orocos Tests, I wonder if it exists any documentation or main classes that
> I could use directly from rtt in my project. If none I will read rtt code,
> but If I could avoid to read this from scratch it would save my time :)

The only way we unit test our components in RTT is by creating 'mock-up'
components, ie use some functionality with 'fake' functions, which only toggle
a flag or so. The unit test then checks if the flag was toggled after using the
functionality.

So this is hardly what you need for unit testing an application component. 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()

I actually like this idea very much. Anyone ?(*)

Peter

(*) Or this is a perfect case to promote the lua scripting, ie to write unit
tests in lua.

On 10/17/2010 09:42 PM, Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that
> there is Orocos Tests, I wonder if it exists any documentation or main
> classes that I could use directly from rtt in my project. If none I
> will read rtt code, but If I could avoid to read this from scratch it
> would save my time :)
>
>
In the dfki toolchain, we use Ruby to read log files or generate
synthetic data and feed that to the components. We then check the
component's outputs either automatically in simple cases or through
plots for more complex ones.
--

Sylvain Joyeux
Space& Security Robotics

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 218-64136
Fax: +49 (0)421 218-64150
E-Mail: robotik [..] ...

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

On Sunday 17 October 2010 21:42:49 Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that there is
> Orocos Tests, I wonder if it exists any documentation or main classes that
> I could use directly from rtt in my project. If none I will read rtt code,
> but If I could avoid to read this from scratch it would save my time :)

The only way we unit test our components in RTT is by creating 'mock-up'
components, ie use some functionality with 'fake' functions, which only toggle
a flag or so. The unit test then checks if the flag was toggled after using the
functionality.

So this is hardly what you need for unit testing an application component. 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()

I actually like this idea very much. Anyone ?(*)

Peter

(*) Or this is a perfect case to promote the lua scripting, ie to write unit
tests in lua.

On 10/17/2010 09:42 PM, Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that
> there is Orocos Tests, I wonder if it exists any documentation or main
> classes that I could use directly from rtt in my project. If none I
> will read rtt code, but If I could avoid to read this from scratch it
> would save my time :)
>
>
In the dfki toolchain, we use Ruby to read log files or generate
synthetic data and feed that to the components. We then check the
component's outputs either automatically in simple cases or through
plots for more complex ones.
--

Sylvain Joyeux
Space& Security Robotics

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 218-64136
Fax: +49 (0)421 218-64150
E-Mail: robotik [..] ...

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

On Sunday 17 October 2010 21:42:49 Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that there is
> Orocos Tests, I wonder if it exists any documentation or main classes that
> I could use directly from rtt in my project. If none I will read rtt code,
> but If I could avoid to read this from scratch it would save my time :)

The only way we unit test our components in RTT is by creating 'mock-up'
components, ie use some functionality with 'fake' functions, which only toggle
a flag or so. The unit test then checks if the flag was toggled after using the
functionality.

So this is hardly what you need for unit testing an application component. 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()

I actually like this idea very much. Anyone ?(*)

Peter

(*) Or this is a perfect case to promote the lua scripting, ie to write unit
tests in lua.

On 10/17/2010 09:42 PM, Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that
> there is Orocos Tests, I wonder if it exists any documentation or main
> classes that I could use directly from rtt in my project. If none I
> will read rtt code, but If I could avoid to read this from scratch it
> would save my time :)
>
>
In the dfki toolchain, we use Ruby to read log files or generate
synthetic data and feed that to the components. We then check the
component's outputs either automatically in simple cases or through
plots for more complex ones.
--

Sylvain Joyeux
Space& Security Robotics

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 218-64136
Fax: +49 (0)421 218-64150
E-Mail: robotik [..] ...

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

On Sunday 17 October 2010 21:42:49 Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that there is
> Orocos Tests, I wonder if it exists any documentation or main classes that
> I could use directly from rtt in my project. If none I will read rtt code,
> but If I could avoid to read this from scratch it would save my time :)

The only way we unit test our components in RTT is by creating 'mock-up'
components, ie use some functionality with 'fake' functions, which only toggle
a flag or so. The unit test then checks if the flag was toggled after using the
functionality.

So this is hardly what you need for unit testing an application component. 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()

I actually like this idea very much. Anyone ?(*)

Peter

(*) Or this is a perfect case to promote the lua scripting, ie to write unit
tests in lua.

On 10/17/2010 09:42 PM, Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that
> there is Orocos Tests, I wonder if it exists any documentation or main
> classes that I could use directly from rtt in my project. If none I
> will read rtt code, but If I could avoid to read this from scratch it
> would save my time :)
>
>
In the dfki toolchain, we use Ruby to read log files or generate
synthetic data and feed that to the components. We then check the
component's outputs either automatically in simple cases or through
plots for more complex ones.
--

Sylvain Joyeux
Space& Security Robotics

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 218-64136
Fax: +49 (0)421 218-64150
E-Mail: robotik [..] ...

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

On Sunday 17 October 2010 21:42:49 Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that there is
> Orocos Tests, I wonder if it exists any documentation or main classes that
> I could use directly from rtt in my project. If none I will read rtt code,
> but If I could avoid to read this from scratch it would save my time :)

The only way we unit test our components in RTT is by creating 'mock-up'
components, ie use some functionality with 'fake' functions, which only toggle
a flag or so. The unit test then checks if the flag was toggled after using the
functionality.

So this is hardly what you need for unit testing an application component. 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()

I actually like this idea very much. Anyone ?(*)

Peter

(*) Or this is a perfect case to promote the lua scripting, ie to write unit
tests in lua.

On 10/17/2010 09:42 PM, Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that
> there is Orocos Tests, I wonder if it exists any documentation or main
> classes that I could use directly from rtt in my project. If none I
> will read rtt code, but If I could avoid to read this from scratch it
> would save my time :)
>
>
In the dfki toolchain, we use Ruby to read log files or generate
synthetic data and feed that to the components. We then check the
component's outputs either automatically in simple cases or through
plots for more complex ones.
--

Sylvain Joyeux
Space& Security Robotics

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 218-64136
Fax: +49 (0)421 218-64150
E-Mail: robotik [..] ...

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

On Sunday 17 October 2010 21:42:49 Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that there is
> Orocos Tests, I wonder if it exists any documentation or main classes that
> I could use directly from rtt in my project. If none I will read rtt code,
> but If I could avoid to read this from scratch it would save my time :)

The only way we unit test our components in RTT is by creating 'mock-up'
components, ie use some functionality with 'fake' functions, which only toggle
a flag or so. The unit test then checks if the flag was toggled after using the
functionality.

So this is hardly what you need for unit testing an application component. 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()

I actually like this idea very much. Anyone ?(*)

Peter

(*) Or this is a perfect case to promote the lua scripting, ie to write unit
tests in lua.

On 10/17/2010 09:42 PM, Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that
> there is Orocos Tests, I wonder if it exists any documentation or main
> classes that I could use directly from rtt in my project. If none I
> will read rtt code, but If I could avoid to read this from scratch it
> would save my time :)
>
>
In the dfki toolchain, we use Ruby to read log files or generate
synthetic data and feed that to the components. We then check the
component's outputs either automatically in simple cases or through
plots for more complex ones.
--

Sylvain Joyeux
Space& Security Robotics

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 218-64136
Fax: +49 (0)421 218-64150
E-Mail: robotik [..] ...

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

On Sunday 17 October 2010 21:42:49 Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that there is
> Orocos Tests, I wonder if it exists any documentation or main classes that
> I could use directly from rtt in my project. If none I will read rtt code,
> but If I could avoid to read this from scratch it would save my time :)

The only way we unit test our components in RTT is by creating 'mock-up'
components, ie use some functionality with 'fake' functions, which only toggle
a flag or so. The unit test then checks if the flag was toggled after using the
functionality.

So this is hardly what you need for unit testing an application component. 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()

I actually like this idea very much. Anyone ?(*)

Peter

(*) Or this is a perfect case to promote the lua scripting, ie to write unit
tests in lua.

On 10/17/2010 09:42 PM, Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that
> there is Orocos Tests, I wonder if it exists any documentation or main
> classes that I could use directly from rtt in my project. If none I
> will read rtt code, but If I could avoid to read this from scratch it
> would save my time :)
>
>
In the dfki toolchain, we use Ruby to read log files or generate
synthetic data and feed that to the components. We then check the
component's outputs either automatically in simple cases or through
plots for more complex ones.
--

Sylvain Joyeux
Space& Security Robotics

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 218-64136
Fax: +49 (0)421 218-64150
E-Mail: robotik [..] ...

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

On Sunday 17 October 2010 21:42:49 Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that there is
> Orocos Tests, I wonder if it exists any documentation or main classes that
> I could use directly from rtt in my project. If none I will read rtt code,
> but If I could avoid to read this from scratch it would save my time :)

The only way we unit test our components in RTT is by creating 'mock-up'
components, ie use some functionality with 'fake' functions, which only toggle
a flag or so. The unit test then checks if the flag was toggled after using the
functionality.

So this is hardly what you need for unit testing an application component. 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()

I actually like this idea very much. Anyone ?(*)

Peter

(*) Or this is a perfect case to promote the lua scripting, ie to write unit
tests in lua.

On 10/17/2010 09:42 PM, Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that
> there is Orocos Tests, I wonder if it exists any documentation or main
> classes that I could use directly from rtt in my project. If none I
> will read rtt code, but If I could avoid to read this from scratch it
> would save my time :)
>
>
In the dfki toolchain, we use Ruby to read log files or generate
synthetic data and feed that to the components. We then check the
component's outputs either automatically in simple cases or through
plots for more complex ones.
--

Sylvain Joyeux
Space& Security Robotics

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 218-64136
Fax: +49 (0)421 218-64150
E-Mail: robotik [..] ...

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

On Sunday 17 October 2010 21:42:49 Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that there is
> Orocos Tests, I wonder if it exists any documentation or main classes that
> I could use directly from rtt in my project. If none I will read rtt code,
> but If I could avoid to read this from scratch it would save my time :)

The only way we unit test our components in RTT is by creating 'mock-up'
components, ie use some functionality with 'fake' functions, which only toggle
a flag or so. The unit test then checks if the flag was toggled after using the
functionality.

So this is hardly what you need for unit testing an application component. 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()

I actually like this idea very much. Anyone ?(*)

Peter

(*) Or this is a perfect case to promote the lua scripting, ie to write unit
tests in lua.

On 10/17/2010 09:42 PM, Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that
> there is Orocos Tests, I wonder if it exists any documentation or main
> classes that I could use directly from rtt in my project. If none I
> will read rtt code, but If I could avoid to read this from scratch it
> would save my time :)
>
>
In the dfki toolchain, we use Ruby to read log files or generate
synthetic data and feed that to the components. We then check the
component's outputs either automatically in simple cases or through
plots for more complex ones.
--

Sylvain Joyeux
Space& Security Robotics

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 218-64136
Fax: +49 (0)421 218-64150
E-Mail: robotik [..] ...

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

On Sunday 17 October 2010 21:42:49 Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that there is
> Orocos Tests, I wonder if it exists any documentation or main classes that
> I could use directly from rtt in my project. If none I will read rtt code,
> but If I could avoid to read this from scratch it would save my time :)

The only way we unit test our components in RTT is by creating 'mock-up'
components, ie use some functionality with 'fake' functions, which only toggle
a flag or so. The unit test then checks if the flag was toggled after using the
functionality.

So this is hardly what you need for unit testing an application component. 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()

I actually like this idea very much. Anyone ?(*)

Peter

(*) Or this is a perfect case to promote the lua scripting, ie to write unit
tests in lua.

On 10/17/2010 09:42 PM, Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that
> there is Orocos Tests, I wonder if it exists any documentation or main
> classes that I could use directly from rtt in my project. If none I
> will read rtt code, but If I could avoid to read this from scratch it
> would save my time :)
>
>
In the dfki toolchain, we use Ruby to read log files or generate
synthetic data and feed that to the components. We then check the
component's outputs either automatically in simple cases or through
plots for more complex ones.
--

Sylvain Joyeux
Space& Security Robotics

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 218-64136
Fax: +49 (0)421 218-64150
E-Mail: robotik [..] ...

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

On Sunday 17 October 2010 21:42:49 Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that there is
> Orocos Tests, I wonder if it exists any documentation or main classes that
> I could use directly from rtt in my project. If none I will read rtt code,
> but If I could avoid to read this from scratch it would save my time :)

The only way we unit test our components in RTT is by creating 'mock-up'
components, ie use some functionality with 'fake' functions, which only toggle
a flag or so. The unit test then checks if the flag was toggled after using the
functionality.

So this is hardly what you need for unit testing an application component. 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()

I actually like this idea very much. Anyone ?(*)

Peter

(*) Or this is a perfect case to promote the lua scripting, ie to write unit
tests in lua.

On 10/17/2010 09:42 PM, Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that
> there is Orocos Tests, I wonder if it exists any documentation or main
> classes that I could use directly from rtt in my project. If none I
> will read rtt code, but If I could avoid to read this from scratch it
> would save my time :)
>
>
In the dfki toolchain, we use Ruby to read log files or generate
synthetic data and feed that to the components. We then check the
component's outputs either automatically in simple cases or through
plots for more complex ones.
--

Sylvain Joyeux
Space& Security Robotics

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 218-64136
Fax: +49 (0)421 218-64150
E-Mail: robotik [..] ...

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

On Sunday 17 October 2010 21:42:49 Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that there is
> Orocos Tests, I wonder if it exists any documentation or main classes that
> I could use directly from rtt in my project. If none I will read rtt code,
> but If I could avoid to read this from scratch it would save my time :)

The only way we unit test our components in RTT is by creating 'mock-up'
components, ie use some functionality with 'fake' functions, which only toggle
a flag or so. The unit test then checks if the flag was toggled after using the
functionality.

So this is hardly what you need for unit testing an application component. 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()

I actually like this idea very much. Anyone ?(*)

Peter

(*) Or this is a perfect case to promote the lua scripting, ie to write unit
tests in lua.

On 10/17/2010 09:42 PM, Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that
> there is Orocos Tests, I wonder if it exists any documentation or main
> classes that I could use directly from rtt in my project. If none I
> will read rtt code, but If I could avoid to read this from scratch it
> would save my time :)
>
>
In the dfki toolchain, we use Ruby to read log files or generate
synthetic data and feed that to the components. We then check the
component's outputs either automatically in simple cases or through
plots for more complex ones.
--

Sylvain Joyeux
Space& Security Robotics

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 218-64136
Fax: +49 (0)421 218-64150
E-Mail: robotik [..] ...

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

On Sunday 17 October 2010 21:42:49 Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that there is
> Orocos Tests, I wonder if it exists any documentation or main classes that
> I could use directly from rtt in my project. If none I will read rtt code,
> but If I could avoid to read this from scratch it would save my time :)

The only way we unit test our components in RTT is by creating 'mock-up'
components, ie use some functionality with 'fake' functions, which only toggle
a flag or so. The unit test then checks if the flag was toggled after using the
functionality.

So this is hardly what you need for unit testing an application component. 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()

I actually like this idea very much. Anyone ?(*)

Peter

(*) Or this is a perfect case to promote the lua scripting, ie to write unit
tests in lua.

On 10/17/2010 09:42 PM, Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that
> there is Orocos Tests, I wonder if it exists any documentation or main
> classes that I could use directly from rtt in my project. If none I
> will read rtt code, but If I could avoid to read this from scratch it
> would save my time :)
>
>
In the dfki toolchain, we use Ruby to read log files or generate
synthetic data and feed that to the components. We then check the
component's outputs either automatically in simple cases or through
plots for more complex ones.
--

Sylvain Joyeux
Space& Security Robotics

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 218-64136
Fax: +49 (0)421 218-64150
E-Mail: robotik [..] ...

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

On Sunday 17 October 2010 21:42:49 Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that there is
> Orocos Tests, I wonder if it exists any documentation or main classes that
> I could use directly from rtt in my project. If none I will read rtt code,
> but If I could avoid to read this from scratch it would save my time :)

The only way we unit test our components in RTT is by creating 'mock-up'
components, ie use some functionality with 'fake' functions, which only toggle
a flag or so. The unit test then checks if the flag was toggled after using the
functionality.

So this is hardly what you need for unit testing an application component. 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()

I actually like this idea very much. Anyone ?(*)

Peter

(*) Or this is a perfect case to promote the lua scripting, ie to write unit
tests in lua.

On 10/17/2010 09:42 PM, Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that
> there is Orocos Tests, I wonder if it exists any documentation or main
> classes that I could use directly from rtt in my project. If none I
> will read rtt code, but If I could avoid to read this from scratch it
> would save my time :)
>
>
In the dfki toolchain, we use Ruby to read log files or generate
synthetic data and feed that to the components. We then check the
component's outputs either automatically in simple cases or through
plots for more complex ones.
--

Sylvain Joyeux
Space& Security Robotics

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 218-64136
Fax: +49 (0)421 218-64150
E-Mail: robotik [..] ...

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

On Sunday 17 October 2010 21:42:49 Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that there is
> Orocos Tests, I wonder if it exists any documentation or main classes that
> I could use directly from rtt in my project. If none I will read rtt code,
> but If I could avoid to read this from scratch it would save my time :)

The only way we unit test our components in RTT is by creating 'mock-up'
components, ie use some functionality with 'fake' functions, which only toggle
a flag or so. The unit test then checks if the flag was toggled after using the
functionality.

So this is hardly what you need for unit testing an application component. 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()

I actually like this idea very much. Anyone ?(*)

Peter

(*) Or this is a perfect case to promote the lua scripting, ie to write unit
tests in lua.

On 10/17/2010 09:42 PM, Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that
> there is Orocos Tests, I wonder if it exists any documentation or main
> classes that I could use directly from rtt in my project. If none I
> will read rtt code, but If I could avoid to read this from scratch it
> would save my time :)
>
>
In the dfki toolchain, we use Ruby to read log files or generate
synthetic data and feed that to the components. We then check the
component's outputs either automatically in simple cases or through
plots for more complex ones.
--

Sylvain Joyeux
Space& Security Robotics

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 218-64136
Fax: +49 (0)421 218-64150
E-Mail: robotik [..] ...

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

On Sunday 17 October 2010 21:42:49 Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that there is
> Orocos Tests, I wonder if it exists any documentation or main classes that
> I could use directly from rtt in my project. If none I will read rtt code,
> but If I could avoid to read this from scratch it would save my time :)

The only way we unit test our components in RTT is by creating 'mock-up'
components, ie use some functionality with 'fake' functions, which only toggle
a flag or so. The unit test then checks if the flag was toggled after using the
functionality.

So this is hardly what you need for unit testing an application component. 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()

I actually like this idea very much. Anyone ?(*)

Peter

(*) Or this is a perfect case to promote the lua scripting, ie to write unit
tests in lua.

On 10/17/2010 09:42 PM, Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that
> there is Orocos Tests, I wonder if it exists any documentation or main
> classes that I could use directly from rtt in my project. If none I
> will read rtt code, but If I could avoid to read this from scratch it
> would save my time :)
>
>
In the dfki toolchain, we use Ruby to read log files or generate
synthetic data and feed that to the components. We then check the
component's outputs either automatically in simple cases or through
plots for more complex ones.
--

Sylvain Joyeux
Space& Security Robotics

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 218-64136
Fax: +49 (0)421 218-64150
E-Mail: robotik [..] ...

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

On Sunday 17 October 2010 21:42:49 Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that there is
> Orocos Tests, I wonder if it exists any documentation or main classes that
> I could use directly from rtt in my project. If none I will read rtt code,
> but If I could avoid to read this from scratch it would save my time :)

The only way we unit test our components in RTT is by creating 'mock-up'
components, ie use some functionality with 'fake' functions, which only toggle
a flag or so. The unit test then checks if the flag was toggled after using the
functionality.

So this is hardly what you need for unit testing an application component. 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()

I actually like this idea very much. Anyone ?(*)

Peter

(*) Or this is a perfect case to promote the lua scripting, ie to write unit
tests in lua.

On 10/17/2010 09:42 PM, Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that
> there is Orocos Tests, I wonder if it exists any documentation or main
> classes that I could use directly from rtt in my project. If none I
> will read rtt code, but If I could avoid to read this from scratch it
> would save my time :)
>
>
In the dfki toolchain, we use Ruby to read log files or generate
synthetic data and feed that to the components. We then check the
component's outputs either automatically in simple cases or through
plots for more complex ones.
--

Sylvain Joyeux
Space& Security Robotics

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 218-64136
Fax: +49 (0)421 218-64150
E-Mail: robotik [..] ...

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

On Sunday 17 October 2010 21:42:49 Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that there is
> Orocos Tests, I wonder if it exists any documentation or main classes that
> I could use directly from rtt in my project. If none I will read rtt code,
> but If I could avoid to read this from scratch it would save my time :)

The only way we unit test our components in RTT is by creating 'mock-up'
components, ie use some functionality with 'fake' functions, which only toggle
a flag or so. The unit test then checks if the flag was toggled after using the
functionality.

So this is hardly what you need for unit testing an application component. 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()

I actually like this idea very much. Anyone ?(*)

Peter

(*) Or this is a perfect case to promote the lua scripting, ie to write unit
tests in lua.

On 10/17/2010 09:42 PM, Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that
> there is Orocos Tests, I wonder if it exists any documentation or main
> classes that I could use directly from rtt in my project. If none I
> will read rtt code, but If I could avoid to read this from scratch it
> would save my time :)
>
>
In the dfki toolchain, we use Ruby to read log files or generate
synthetic data and feed that to the components. We then check the
component's outputs either automatically in simple cases or through
plots for more complex ones.
--

Sylvain Joyeux
Space& Security Robotics

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 218-64136
Fax: +49 (0)421 218-64150
E-Mail: robotik [..] ...

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

On Sunday 17 October 2010 21:42:49 Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that there is
> Orocos Tests, I wonder if it exists any documentation or main classes that
> I could use directly from rtt in my project. If none I will read rtt code,
> but If I could avoid to read this from scratch it would save my time :)

The only way we unit test our components in RTT is by creating 'mock-up'
components, ie use some functionality with 'fake' functions, which only toggle
a flag or so. The unit test then checks if the flag was toggled after using the
functionality.

So this is hardly what you need for unit testing an application component. 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()

I actually like this idea very much. Anyone ?(*)

Peter

(*) Or this is a perfect case to promote the lua scripting, ie to write unit
tests in lua.

On 10/17/2010 09:42 PM, Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that
> there is Orocos Tests, I wonder if it exists any documentation or main
> classes that I could use directly from rtt in my project. If none I
> will read rtt code, but If I could avoid to read this from scratch it
> would save my time :)
>
>
In the dfki toolchain, we use Ruby to read log files or generate
synthetic data and feed that to the components. We then check the
component's outputs either automatically in simple cases or through
plots for more complex ones.
--

Sylvain Joyeux
Space& Security Robotics

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 218-64136
Fax: +49 (0)421 218-64150
E-Mail: robotik [..] ...

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

On Sunday 17 October 2010 21:42:49 Willy Lambert wrote:
> Hi all,
>
> I would like to set up unit testing for my project. As I saw that there is
> Orocos Tests, I wonder if it exists any documentation or main classes that
> I could use directly from rtt in my project. If none I will read rtt code,
> but If I could avoid to read this from scratch it would save my time :)

The only way we unit test our components in RTT is by creating 'mock-up'
components, ie use some functionality with 'fake' functions, which only toggle
a flag or so. The unit test then checks if the flag was toggled after using the
functionality.

So this is hardly what you need for unit testing an application component. 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()

I actually like this idea very much. Anyone ?(*)

Peter

(*) Or this is a perfect case to promote the lua scripting, ie to write unit
tests in lua.