On Thu, Aug 30, 2012 at 10:44 PM, Adam Murdoch <[email protected]>wrote:
> > On 30/08/2012, at 6:24 PM, Hans Dockter wrote: > > I think it would be great if we could tackle the problem of test > aggregation in the near future. Let's provide some background here: > > - Gradle has no concept of test aggregation or report aggregation in > general build in. > > What you can do now: Add a report task in the root project and configure > it by iterating over all subprojects and add their xml test results > directory to this task. See for example the Gradle build itself: > https://github.com/gradle/gradle/blob/master/buildSrc/src/main/groovy/org/gradle/build/TestReportAggregator.groovy. > You could also use the ant junit report task for this purpose. > > Problems: > - It is not straight forward to get such a generated report. > - The generated report has no notion to which subproject a test report > belongs. That makes it more or less unusable for larger projects as you > don't know easily who is resposible, where to look for the class (if you > don't have the full source tree in your IDE). > - As far as I know Maven has a similar issue. Jenkins helps out here by > creating aggregated report with a subproject affinity. But I think it > should be a capability of the build system. > > It depends a lot on the specific organisational structure and the type of > project whether you are interested in reports per subproject, aggregated > reports or both. So Gradle should provide a nice toolkit to easily build > what you want with a test report aggregation that automatically does the > wiring for you and generates reports that have the knowledge of which > subproject the report page belongs too. > > There are other aggregated reports where there is usually no subproject > knowledge needed (e.g. javadoc). You can generate this pretty straight > forward with Gradle already: See: > https://github.com/gradle/gradle/blob/master/subprojects/docs/docs.gradle#L250 > But it would be probably nice if this concept is also more baked in on a > high level way. > > Not sure if it is worth trying to model the concept of aggregation > independent of reports (e.g. uberjars, aggregating tasks in general). > > Being smart with aggregated reports will also make our future site plugin > much more valuable. > > > I think I'd rather go with summarising rather than aggregating to solve > the use case. That is, add an overview report that summarises the results > from the individual reports and links to them. Some, but not all, of the > detail would be hoisted up to the overview report. > This is an interesting idea. One downside will be unidirectional navigation I guess. Hans > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > >
