On 31/08/2012, at 6:49 AM, Hans Dockter wrote: > > > 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.
The individual reports would be 'summary aware', in that they would be able to provide some details to the overview report. It can work in the other direction, so that the overview report can provide some navigation context to those detail reports that care. So, you're aggregating multiple reports into a whole, rather than having a bunch of separate reports that aggregate a particular thing. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
