* testing with Ravenscar task
@ 2004-10-08 22:27 Lionel Draghi
2004-10-08 23:00 ` Ed Falis
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Lionel Draghi @ 2004-10-08 22:27 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: testing with Ravenscar task
2004-10-08 22:27 testing with Ravenscar task Lionel Draghi
@ 2004-10-08 23:00 ` Ed Falis
2004-10-09 22:23 ` Lionel Draghi
2004-10-09 19:38 ` Niklas Holsti
2004-10-10 2:01 ` bh
2 siblings, 1 reply; 8+ messages in thread
From: Ed Falis @ 2004-10-08 23:00 UTC (permalink / raw)
Lionel,
I'd expect that you would need to find a way to explicitly kill tasks
created in your unit tests.
- Ed
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: testing with Ravenscar task
2004-10-08 22:27 testing with Ravenscar task Lionel Draghi
2004-10-08 23:00 ` Ed Falis
@ 2004-10-09 19:38 ` Niklas Holsti
2004-10-09 22:25 ` Lionel Draghi
2004-10-10 2:01 ` bh
2 siblings, 1 reply; 8+ messages in thread
From: Niklas Holsti @ 2004-10-09 19:38 UTC (permalink / raw)
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
. @ .
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: testing with Ravenscar task
2004-10-08 23:00 ` Ed Falis
@ 2004-10-09 22:23 ` Lionel Draghi
0 siblings, 0 replies; 8+ messages in thread
From: Lionel Draghi @ 2004-10-09 22:23 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: testing with Ravenscar task
2004-10-09 19:38 ` Niklas Holsti
@ 2004-10-09 22:25 ` Lionel Draghi
2004-10-10 18:25 ` Niklas Holsti
0 siblings, 1 reply; 8+ messages in thread
From: Lionel Draghi @ 2004-10-09 22:25 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: testing with Ravenscar task
2004-10-08 22:27 testing with Ravenscar task Lionel Draghi
2004-10-08 23:00 ` Ed Falis
2004-10-09 19:38 ` Niklas Holsti
@ 2004-10-10 2:01 ` bh
2004-10-11 22:25 ` Lionel Draghi
2 siblings, 1 reply; 8+ messages in thread
From: bh @ 2004-10-10 2:01 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: testing with Ravenscar task
2004-10-09 22:25 ` Lionel Draghi
@ 2004-10-10 18:25 ` Niklas Holsti
0 siblings, 0 replies; 8+ messages in thread
From: Niklas Holsti @ 2004-10-10 18:25 UTC (permalink / raw)
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
. @ .
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: testing with Ravenscar task
2004-10-10 2:01 ` bh
@ 2004-10-11 22:25 ` Lionel Draghi
0 siblings, 0 replies; 8+ messages in thread
From: Lionel Draghi @ 2004-10-11 22:25 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2004-10-11 22:25 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-10-08 22:27 testing with Ravenscar task Lionel Draghi
2004-10-08 23:00 ` Ed Falis
2004-10-09 22:23 ` Lionel Draghi
2004-10-09 19:38 ` Niklas Holsti
2004-10-09 22:25 ` Lionel Draghi
2004-10-10 18:25 ` Niklas Holsti
2004-10-10 2:01 ` bh
2004-10-11 22:25 ` Lionel Draghi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox