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,29d8139471e3f53e
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII
Path: 
 g2news1.google.com!news3.google.com!feeder.news-service.com!feeder.news-service.com!85.214.198.2.MISMATCH!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail
From: "J-P. Rosen" <rosen@adalog.fr>
Newsgroups: comp.lang.ada
Subject: Re: Preventing type extensions
Date: Tue, 14 Sep 2010 19:04:01 +0200
Organization: Adalog
Message-ID: <i6o9u1$9ug$2@news.eternal-september.org>
References: <87iq2bfenl.fsf@mid.deneb.enyo.de>
 <874odv9npv.fsf@ludovic-brenta.org> <87y6b7cedd.fsf@mid.deneb.enyo.de>
 <66a3704c-54f9-4f04-8860-aa12f516134b@t3g2000vbb.googlegroups.com>
 <87d3sib44t.fsf@mid.deneb.enyo.de>
 <134q4k2ly2pf4$.17nlv1q6q5ivo.dlg@40tude.net>
 <4c8dec8e$0$6990$9b4e6d93@newsspool4.arcor-online.net>
 <epkb3s8dfxk0$.1qdvo5vg2fsgh.dlg@40tude.net>
 <8f6cceFrv2U1@mid.individual.net> <i6m402$gjp$1@news.eternal-september.org>
 <8f97d6FobnU1@mid.individual.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 14 Sep 2010 17:04:01 +0000 (UTC)
Injection-Info: mx03.eternal-september.org;
 posting-host="z/xN1DBP8RUb+r9ug/i0hg";
	logging-data="10192"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX19o0kUoli9kbrX/RQH/QJ1B"
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr;
 rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
In-Reply-To: <8f97d6FobnU1@mid.individual.net>
Cancel-Lock: sha1:xW4yNtvVhszfQCUjZyjBKDJKvRc=
Xref: g2news1.google.com comp.lang.ada:14077
Date: 2010-09-14T19:04:01+02:00
List-Id: <comp.lang.ada>

Le 14/09/2010 14:16, Niklas Holsti a �crit :
> J-P. Rosen wrote:
>> Le 13/09/2010 12:23, Niklas Holsti a �crit :
>>> Some time ago on c.l.a. we had a long discussion on the goodness or
>>> badness of re-dispatch, without coming to an agreement. I don't want to
>>> repeat that discussion, just to point out, again, that Dmitry's opinion
>>> is not universal.
>>>
>> <shameless_plug>
>> I expect this to be a major topic of discussion at the OO for HR systems
>> at SIGAda, since redispatch is what is causing the exponential explosion
>> of tests.
> 
> Perhaps I am revealing my scanty knowledge of HR testing, but the
> "exponential explosion of tests" is news to me. Which phase of testing,
> and which coverage criterion, is affected so much by redispatching?
> Integration test? Some kind of path test?
> 
It's about MC/DC coverage. According to OOTiA, a dispatching call is
equivalent to a "big case" for all possible classes (assumed to be
known). Therefore, each dispatching call must be stubbed for all
classes, and the tests have to exercise every branch of the "big case".
-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr