On 12/2/2014 3:31 PM, Michael Wechner wrote:
> I am trying to setup a testing environment, which is running tests
> incrementally based on changed files, instead of running whole builds.
>
> I would like to try this for Lucene/Solr, hence I am trying to
> understand better the relationship between individual code changes and
> associated tests. For example I have noticed to the following change:
>
> git diff --name-only 641ed06..cb4fc89
> lucene/core/src/java/org/apache/lucene/codecs/compressing/CompressingStoredFieldsFormat.java
>
> and if I understand correctly, then the following tests would have to be 
> executed:
>
> lucene/core/src/test/org/apache/lucene/codecs/compressing/TestCompressingStoredFieldsFormat.java
> lucene/test-framework/src/java/org/apache/lucene/codecs/compressing/CompressingCodec.java
>
> is that correct?

The test dependency tree for this particular class is *EXTENSIVE* and
not very easy to track down.

CompressingStoredFieldsFormat is the parent class for
Lucene50StoredFieldsFormat.  It is directly referenced by three classes
in addition to the direct descendant.  Here's a screenshot showing all
direct references in branch_5x:

https://www.dropbox.com/s/3pb4kljvdbd6xug/CompressingStoredFieldsFormat-eclipse.png?dl=0

Lucene50StoredFieldsFormat is used by a few classes, one of which is
Lucene50Codec:

https://www.dropbox.com/s/0ibnw87m6rveinv/Lucene50StoredFieldsFormat.png?dl=0

Lucene50Codec is extremely central to almost everything the unreleased
Lucene 5.x does if it is using default settings, so a very large number
of tests would be affected by a change in the compressed stored field
format.  Just for giggles, I grabbed a screenshot of the classes that
directly reference Lucene50Codec:

https://www.dropbox.com/s/eqq30uvckc8b19d/Lucene50Codec.png?dl=0

The build system includes the ability to use Clover if it is present ...
I don't know much about it, except that it's related to determining test
coverage for parts of the software.  Perhaps a clover report could give
you the info you need?

https://www.atlassian.com/software/clover/overview

Aside from that ... running the entire test suite multiple times
whenever you change anything is the best option.  The test system
randomizes a large number of options on each test run, so running the
tests multiple times will test many different combinations.  A very
large number of bugs have been discovered and fixed because of that
randomization.

Thanks,
Shawn


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to