From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19864 invoked by alias); 26 Jun 2003 08:53:17 -0000 Mailing-List: contact mauve-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: mauve-discuss-owner@sources.redhat.com Received: (qmail 19825 invoked from network); 26 Jun 2003 08:53:15 -0000 Received: from unknown (HELO mwinf0202.wanadoo.fr) (193.252.22.29) by sources.redhat.com with SMTP; 26 Jun 2003 08:53:15 -0000 Received: from localhost.localdomain (unknown [193.251.35.109]) by mwinf0202.wanadoo.fr (SMTP Server) with ESMTP id 21C99A400174; Thu, 26 Jun 2003 10:53:14 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Yan Georget Reply-To: yan.georget@koalog.com Organization: Koalog To: Stephen Crawley Subject: Re: Mauve Code Coverage Date: Thu, 26 Jun 2003 08:53:00 -0000 User-Agent: KMail/1.4.3 References: <200306260028.h5Q0SUSa026353@piglet.dstc.edu.au> In-Reply-To: <200306260028.h5Q0SUSa026353@piglet.dstc.edu.au> Cc: mauve-discuss@sources.redhat.com MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200306261049.31453.yan.georget@koalog.com> X-SW-Source: 2003-q2/txt/msg00043.txt.bz2 > I think this is a good idea in principle. But a better idea would be > for you to run the coverage tool on Mauve/Classpath/some VM and post the > results. If you could set something up to do this automatically, that > would be even better! Not sure, it is much more rewarding for developpers (here, test writers) to= =20 run the code coverage themselves than letting a quality engineer (here,=20 Koalog) do it for them. > Another point is that coverage testing will only really help if people > volunteer to write good test cases to fill in the gaps. That's the point. See above. > Finally, coverage testing won't tell us about test cases that are > incorrect; e.g. ones that test for implementation specific behavior, or > ones that don't work against various Sun JDK's. In other words, Mauve's > limitations are not just restricted to coverage. In a usual projet, you check that all the test pass under several environme= nts=20 (OS and JDK). In your case, you would also check that the coverage results= =20 are the same under these environments. Computing the code coverage is indeed a simple but powerful way to test the= =20 tests, which is exactly what you want to do here. What do you think? Yan