Return-Path: Delivered-To: apmail-lucene-java-dev-archive@www.apache.org Received: (qmail 98682 invoked from network); 5 Aug 2009 09:30:39 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 5 Aug 2009 09:30:39 -0000 Received: (qmail 9942 invoked by uid 500); 5 Aug 2009 09:30:46 -0000 Delivered-To: apmail-lucene-java-dev-archive@lucene.apache.org Received: (qmail 9842 invoked by uid 500); 5 Aug 2009 09:30:46 -0000 Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-dev@lucene.apache.org Delivered-To: mailing list java-dev@lucene.apache.org Received: (qmail 9834 invoked by uid 99); 5 Aug 2009 09:30:46 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Aug 2009 09:30:46 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Aug 2009 09:30:36 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id C8C09234C044 for ; Wed, 5 Aug 2009 02:30:14 -0700 (PDT) Message-ID: <640369598.1249464614817.JavaMail.jira@brutus> Date: Wed, 5 Aug 2009 02:30:14 -0700 (PDT) From: "Nick Pellow (JIRA)" To: java-dev@lucene.apache.org Subject: [jira] Commented: (LUCENE-1769) Fix wrong clover analysis because of backwards-tests, upgrade clover to 2.4.3 or better In-Reply-To: <1679936280.1248974414790.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/LUCENE-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739388#action_12739388 ] Nick Pellow commented on LUCENE-1769: ------------------------------------- bq. we have some "untested" code parts (because the methods are never called by core). Are these untested parts in the test cases? To generate the code coverage of an application, the test cases don't need to be instrumented. Instrumentation of tests cases is needed only for "per-test coverage", which you may not need for your regression tests bq. so the linkage in the clover reports between tests and source code are completely broken. In what way is it broken? Are the test method names missing, or do you have duplicate test methods? There should be one testMethod listed for each test run that occured. bq. Is there any possibility to also fold in the coverage of the backwards tests, but without linking the test source code to it? I'm guessing that not instrumenting your old tests should do what you want. bq. Should we generate two clover reports (one for core, one for backwards)? This is also an option. Clover2 will link the reports together if you generate them in the same block. > Fix wrong clover analysis because of backwards-tests, upgrade clover to 2.4.3 or better > --------------------------------------------------------------------------------------- > > Key: LUCENE-1769 > URL: https://issues.apache.org/jira/browse/LUCENE-1769 > Project: Lucene - Java > Issue Type: Bug > Components: Build > Affects Versions: 2.9 > Reporter: Uwe Schindler > Attachments: clover.license, LUCENE-1769.patch, LUCENE-1769.patch, nicks-LUCENE-1769.patch > > > This is a followup for [http://www.lucidimagination.com/search/document/6248d6eafbe10ef4/build_failed_in_hudson_lucene_trunk_902] > The problem with clover running on hudson is, that it does not instrument all tests ran. The autodetection of clover 1.x is not able to find out which files are the correct tests and only instruments the backwards test. Because of this, the current coverage report is only from the backwards tests running against the current Lucene JAR. > You can see this, if you install clover and start the tests. During test-core no clover data is added to the db, only when backwards-tests begin, new files are created in the clover db folder. > Clover 2.x supports a new ant task, that can be used to specify the files, that are the tests. It works here locally with clover 2.4.3 and produces a really nice coverage report, also linking with test files work, it tells which tests failed and so on. > I will attach a patch, that changes common-build.xml to the new clover version (other initialization resource) and tells clover where to find the tests (using the test folder include/exclude properties). > One problem with the current patch: It does *not* instrument the backwards branch, so you see only coverage of the core/contrib tests. Getting the coverage also from the backwards tests is not easy possible because of two things: > - the tag test dir is not easy to find out and add to element (there may be only one of them) > - the test names in BW branch are identical to the trunk tests. This completely corrupts the linkage between tests and code in the coverage report. > In principle the best would be to generate a second coverage report for the backwards branch with a separate clover DB. The attached patch does not instrument the bw branch, it only does trunk tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org For additional commands, e-mail: java-dev-help@lucene.apache.org