From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,b74b00d13dd5feab X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news.glorb.com!newsgate.cistron.nl!news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed.bahnhof.se!feeder1.news.jippii.net!reader1.news.jippii.net!53ab2750!not-for-mail Message-ID: <41697E85.5040306@nowhere.fi> From: Niklas Holsti Organization: Tidorum Ltd User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: testing with Ravenscar task References: <41671438$0$1122$626a14ce@news.free.fr> <41683E3F.1090209@nowhere.fi> <41686531$0$6159$626a14ce@news.free.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 10 Oct 2004 21:25:09 +0300 NNTP-Posting-Host: 194.29.197.24 X-Complaints-To: newsmaster@saunalahti.com X-Trace: reader1.news.jippii.net 1097432714 194.29.197.24 (Sun, 10 Oct 2004 21:25:14 EEST) NNTP-Posting-Date: Sun, 10 Oct 2004 21:25:14 EEST Xref: g2news1.google.com comp.lang.ada:5008 Date: 2004-10-10T21:25:09+03:00 List-Id: 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 . @ .