Hans Dockter-2 wrote > > 1.) The events(Object... events) is not additive but replaces existing > values. This is different to the behavior in other parts of the Gradle > DSL. > It confused me a little bit when I used the events method together with > some of the alternative configure methods (e.g. showStandardStreams). >
I reasoned that in the case of test events, one would usually want to override, and hence chose this as the method's behavior. If the method's behavior was additive (like it was in the beginning), one would have to write `events = [TestLogEvent.PASSED]` instead of `events "passed"` to see just `passed` events. This is because lifecycle and debug levels have non-empty defaults. The fact that I once was perplexed that `events "passed"` still gave me `failed` events convinced me to change the behavior to overriding. This reflects the general problem that in our DSLs, often only the (additive) method is convenient to use, and there is no convenient way to get overriding behavior. A partial solution would be to make the setter accept Set (or Object) rather than Set<TestLogEvent>. This would allow to use strings instead of enum values, but would still require a list literal (plus more sophisticated type conversions). I haven't checked if Gradle is happy with getter and setter having different types. Note that I used the test logging DSL as an initial test bed for how our configuration DSLs could look like in the future (in terms of type conversions and (auto-generated) convenience methods). Regarding the add vs. override problem, I can think of the following solutions: * Setter always overrides, method always adds (more or less what we do today). For this we should make the setter as convenient to use as possible (in particular regarding type conversions). Won't get around having to use a list literal though, which is somewhat ugly. * User has a generic way to specify whether a method has additive or overriding behavior. Something like: `events "started", "failed", override: true` * DSL author can select on a case-by-case basis whether the (auto-generated) method is additive or overriding, e.g. by placing an annotation on the property. This is what I did for `events`. Hans Dockter-2 wrote > > 2.) What about the message property of the exception object? > The idea behind the `short` exception format was to keep the output to a one-liner, similar to most other default log output in Gradle. If we are OK with two lines, then we could maybe print the first line of the message, and the stack trace (entry point) in the second line. This would result in more informative output for JUnit assertions, but not for Spock, Groovy, Hamcrest, and possibly others. Hans Dockter-2 wrote > > 3.) For learning about why an assertEquals method has failed, I need to > configure the following: > > showExceptions true > exceptionFormat 'FULL' > events 'FAILED' > stackTraceFilters 'ENTRY_POINT' > In fact, this should be enough: exceptionFormat "full" (and optionally a stack trace filter) It would be nice to default to the "truncate" stack trace filter, but since filters (and also non-empty defaults) always bear some risks, I didn't go for it. Opinions welcome. Hans Dockter-2 wrote > > What about making this more convenient? Would it help to display the > e.message? > I agree that it might be better to provide more information by default. I wasn't sure and therefore opted for a one-liner, which seems to be Gradle's default approach to logging, together with a one-line switch (see above) to get exhaustive failure logging. More opinions welcome. Cheers, Peter -- View this message in context: http://gradle.1045684.n5.nabble.com/New-Test-Logging-tp5709881p5709882.html Sent from the gradle-dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
