testing with Ravenscar task

testing with Ravenscar task

[Lionel Draghi]

Hi,

I am curious about native tests on code embedding Ravenscar task.
Those task are supposed never end. (Behaviour is implementation 
dependent in this case, as far as I remember).

So, how can I have my unit tests ending normally, and in a way portable 
amonst compiler?
(I once experienced problems with tests killed from the OS, with gcov 
file that where not saved).

I am not in the situation to work on this topic, it's just curiosity.

-- 
Lionel Draghi

Re: testing with Ravenscar task

[Ed Falis]

Lionel,

I'd expect that you would need to find a way to explicitly kill tasks  
created in your unit tests.

- Ed

Re: testing with Ravenscar task

[Lionel Draghi]

Ed Falis wrote:
> Lionel,
> 
> I'd expect that you would need to find a way to explicitly kill tasks  
> created in your unit tests.

As I understand this point from the Ravenscar profile, what may result 
from an explicit abort or exit is implementation defined. Program_Error 
is a possible consequence.
I am pretty sure I will find a way to complete the test, have all open 
files closed, and in the GNAT case have gcov files OK, etc.
But I was wondering if there is a portable way to do this, so that the 
same tests sources could be used with several compilers.

Anyway, thanks Ed.

-- 
Lionel

Re: testing with Ravenscar task

[Niklas Holsti]

Lionel Draghi wrote:
> Hi,
> 
> I am curious about native tests on code embedding Ravenscar task.
> Those task are supposed never end. (Behaviour is implementation 
> dependent in this case, as far as I remember).
> 
> So, how can I have my unit tests ending normally, and in a way portable 
> amonst compiler?

Ravenscar task bodies (at least those with just one suspension point) 
can usually be made very simple by putting the real computation in a 
procedure defined outside the task. This procedure can be unit-tested in 
the normal way. The task body is then a few lines for the eternal loop, 
the activation condition (delay-until or entry call) and the procedure 
call, hardly worth unit-testing.

If you put the tasks and computational procedures in different packages 
you can avoid "withing" the task packages in the unit tests and so avoid 
the task termination issue.

A nice side effect of this package structure is that elaboration 
circularities caused by tasks are much reduced.

Niklas Holsti
Tidorum Ltd

niklas holsti tidorum fi
       .      @       .

Re: testing with Ravenscar task

[Lionel Draghi]

Niklas Holsti wrote:
...
> Ravenscar task bodies (at least those with just one suspension point) 
> can usually be made very simple by putting the real computation in a 
> procedure defined outside the task. This procedure can be unit-tested in 
> the normal way.
I agree with you, Niklas.
But what if I want to do some integration tests?
Switching directly from unit tests stricto sensu to tests on the whole 
executable may be a big step.

-- 
Lionel Draghi

Re: testing with Ravenscar task

[Niklas Holsti]

Lionel Draghi wrote:
> Niklas Holsti wrote:
> ...
> 
>> Ravenscar task bodies (at least those with just one suspension point) 
>> can usually be made very simple by putting the real computation in a 
>> procedure defined outside the task. This procedure can be unit-tested 
>> in the normal way.
> 
> I agree with you, Niklas.
> But what if I want to do some integration tests?
> Switching directly from unit tests stricto sensu to tests on the whole 
> executable may be a big step.

If by integration test you mean putting together some, but not all, 
modules of the program, and checking that they work together, then one 
way to do that is to make the test driver (the main procedure for the 
integration test) call those "computational" procedures for each task, 
one by one, in the order they would (or should) be called by the actual 
tasks in the tested scenario. You would again omit to "with" the actual 
tasks so that the test driver is totally in charge. Of course this does 
not give the true timing, but the test instrumentation clobbers timing 
anyway.

If you have a large program with lots of tasks, this approach gets 
cumbersome in the later stages of a bottom-up integration process as the 
test driver becomes very large. To solve that one could "with" the tasks 
for the modules that have been tested, considering these modules as 
trusted black boxes with autonomous activity, while still driving the 
new modules-under-test from the test driver. Of course this brings back 
the problems with task termination and gcov output.

--
Niklas Holsti
Tidorum Ltd

niklas holsti tidorum fi
       .      @       .

Re: testing with Ravenscar task

[bh]

We actually unit test on the real target, and after running
the various test cases, simply use the debugger to 'stop'
the Ada execution. Then we wrote a procedure to dump the
gcov data to the host for post analysis and manually invoke
it from the debugger.

-bh

"Lionel Draghi" <Lionel.nospam.Draghi@Ada-France.org> wrote in message
news:41671438$0$1122$626a14ce@news.free.fr...
> Hi,
>
> I am curious about native tests on code embedding Ravenscar task.
> Those task are supposed never end. (Behaviour is implementation
> dependent in this case, as far as I remember).
>
> So, how can I have my unit tests ending normally, and in a way portable
> amonst compiler?
> (I once experienced problems with tests killed from the OS, with gcov
> file that where not saved).
>
> I am not in the situation to work on this topic, it's just curiosity.
>
> --
> Lionel Draghi

Re: testing with Ravenscar task

[Lionel Draghi]

bh wrote:
> We actually unit test on the real target, and after running
> the various test cases, simply use the debugger to 'stop'
> the Ada execution. Then we wrote a procedure to dump the
> gcov data to the host for post analysis and manually invoke
> it from the debugger.
> 
> -bh
Why not: no constraint on the code/design, but an advanced use of the tools.

Thank you BH.