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. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
