[
https://issues.apache.org/jira/browse/LUCENE-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739379#action_12739379
]
Uwe Schindler commented on LUCENE-1769:
---------------------------------------
Hi Nick,
I have another question about the instrumentation.
You may have noticed, that "ant test" runs all tests from core and crontrib,
which are (now) correctly instrumented. After this, a special backwards branch
is checked out from SVN containing all tests from Lucene 2.4 (with minor
modifications when internal fields/methods were tested that changed), to test
backwards compatibility. These tests are *compiled against the old 2.4 Lucene
JAR* and then packaged as jar. After that these tests are *run against the
trunk* (by that we test that drop-in-replacements of the Lucene JAR work with
2.9 and also that all backwards compatibility layers in Lucene core still work
the same as before).
All tests in Lucene Core use only the new API, so to test the old APIs, the
backwards tests do their job for the deprecated methods. The problem is now,
that I cannot simply add this special build step to the clover analysis,
because all bw test names are the same as in 2.9, so the linkage in the clover
reports between tests and source code are completely broken. If I leave out the
backwards tests (they are currently not in <testsources>, this is the current
state of the latest patch), we have some "untested" code parts (because the
methods are never called by core).
Is there any possibility to also fold in the coverage of the backwards tests,
but without linking the test source code to it? Should we generate two clover
reports (one for core, one for backwards)?
> 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, <testsources> 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 <testsources> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
