In my opinion it really all comes down to how confident are you that your changes did not cause regressions when you build that module/project (with its tests executed). Relying on the execution of an external module/project for that confidence is a recipe for problems in my experience.
We've struggled with this back and forth in Hibernate because most of our tests are more the functional variety; we have very few unit tests. For numerous reasons we tried moving the test suite into a separate module as you suggest. In my experience that caused a lot of problems where developers would not even run the test suite, so be careful. Logically speaking I think a separation of testing concerns makes sense, but that does not necessarily mean separate modules. In Gradle you might have a unit-test source set and a functional-test source set. Or you might decide to keep unit tests with the module they test and move functional-tests to a separate module. As long as after you build the module in question you are confident you have introduced no regressions I think that whatever path you choose here will be fine. By the way, I've never experienced the types of difficulties you outline with regards to IDE set up nor your points about checkstyle, documentation, etc so hard for me to speak to them specifically On Sunday, October 17, 2010, at 07:02 am, Etienne Studer wrote: > This is exactly what we do in our multi-project setup, too. And for the > same reasons you listed. It works well for me. > > I'd be interested to hear, too, what other developers think and experience. > > Regards, Etienne > > On 17.10.2010, at 13:50, Dierk König wrote: > > Here is a small design question: > > why do we need a special handling for testing > > in the source sets, tasks, configurations, etc? > > > > Having played a little with multi-project setup, > > it seems to me that a separate test project > > that depends on the main project would > > just as well do the job without introducing > > any special handling. > > > > IDEs would map this as dependent modules > > and would thus provide the same support as > > today. > > > > Some tasks may become easier like excluding > > test code from coverage, checkstyle, > > and documentation. > > > > Any opinions on the benefits/downsides of > > this? Has someone ever tried this setup? > > > > cheers > > Dierk > > > > --------------------------------------------------------------------- > > > > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > Etienne Studer > Senior Software Developer > > Canoo Engineering AG > Kirschgartenstrasse 5 > CH-4051 Basel > > T +41 61 228 94 44 > F +41 61 228 94 49 > > [email protected] > www.canoo.com > > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email --- Steve Ebersole <[email protected]> http://hibernate.org --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
