[
https://issues.apache.org/jira/browse/OAK-3862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15093926#comment-15093926
]
Chetan Mehrotra commented on OAK-3862:
--------------------------------------
{quote}
I thought about this suggestion, but I find this solution sub-optimal. Suppose
you have an oak-it module containing every integration test in Oak: this module
needs only to know which implementations to run the tests against. On the other
hand, suppose we apply your solution: oak-segment would need to have a
knowledge about every integration test in oak-core, with the potential of
missing some tests if we don't keep this knowledge up to date.
{quote}
Such things can be simplified via use of
[Categories|https://github.com/junit-team/junit/wiki/Categories]. In Oak we
somewhat use a similar approach with RepositoryStub which allows test in
jackrabbit-core to be executed with various modules in Oak. See
[QueryJcrTestIT|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-lucene/src/test/java/org/apache/jackrabbit/oak/jcr/query/QueryJcrTestIT.java#L53]
which is custom suite listing all such jackrabbit-core test. This can be
improved via use of Categories.
In addition I would prefer to have test closer to the logic being tested unless
they are testing bigger usecase flows. So TreeTest should live _near_ tree
implementation logic.
{quote}
Moreover, I fear that your solution would make oak-segment a second-class
citizen: since oak-core comes before oak-segment in the Maven build plan, no
integration test for oak-segment will be ever run if some integration test
fails in oak-core.
{quote}
I do not think it makes any stuff second class. For e.g. currently oak-lucene
run same query test which are run in oak-core or oak-jcr. And that has not been
a problem. You can use [fail at
end|https://maven.apache.org/guides/mini/guide-multiple-modules.html] feature
to ensure test are run against different module even in case of failure.
For the modularization approach which impact the whole project it would be
preferable if changes are done gradually. So some approach might not be optimal
(to start with) but would allow gradual changes to reach the end goal. If
required we can carve out separate oak-it module. But then that should be done
as 3rd or 4th step say after extracting out oak-segment and oak-document.
Making it a prerequisite would make such refactoring riskier IMHO.
> Move integration tests in a different Maven module
> --------------------------------------------------
>
> Key: OAK-3862
> URL: https://issues.apache.org/jira/browse/OAK-3862
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Reporter: Francesco Mari
> Assignee: Francesco Mari
> Fix For: 1.4
>
>
> While moving the Segment Store and related packages into its own bundle, I
> figured out that integration tests contained in {{oak-core}} contribute to a
> cyclic dependency between the (new) {{oak-segment}} bundle and {{oak-core}}.
> The dependency is due to the usage of {{NodeStoreFixture}} to instantiate
> different implementations of {{NodeStore}} in a semi-transparent way.
> Tests depending on {{NodeStoreFixture}} are most likely integration tests. A
> clean solution to this problem would be to move those integration tests into
> a new Maven module, referencing the API and implementation modules as needed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
