groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thibault Kruse <tibokr...@googlemail.com>
Subject Re: Should PowerAsserts be more verbose?
Date Wed, 26 Aug 2015 14:07:08 GMT
So here is the current state in my branch, for code:

String es = 'a \'b'
String ml = 'a\n \'b'
StringBuffer b = new StringBuffer('x')
def toNull = new Object() {public String toString() {null}}
int[] ia = [1, 2, 3, 4]
List sl = ['a', 'b']
String[] sa = ['a', 'b'] as String[]
Set ss = ['a', 'b'] as Set

class Person {String name = "John Doe"; String toString() {name}}
Map m = [a: 'b', c: 'd']

assert '' == [es, ml, b, toNull, ia, sl, sa, ss, new Person(), m]



assert '' == [es, ml, b, toNull, ia, sl, sa, ss, new Person(), new Car(), m]
          |   |   |   |  |       |   |   |   |   |             |          |
          |   a 'b|   x  |       |   |   |   |   John Doe      |
   [a:b, c:d]
          false   |      |       |   |   |   [a, b]            Car@47caa0f
                  |      |       |   |   [a, b]
                  |      |       |   [a, b]
                  |      |       [1, 2, 3, 4]
                  |      foo$1@1480c116 (toString() == null)
                  a
                   'b


AFTER

assert '' == [es, ml, b, toNull, ia, sl, sa, ss, new Person(), new Car(), m]
          |   |   |   |  |       |   |   |   |   |             |          |
          |   |   |   |  |       |   |   |   |   |             |
   ['a':'b', 'c':'d']
          |   |   |   |  |       |   |   |   |   |             Car@1815b417
          |   |   |   |  |       |   |   |   |   {John Doe}  Person@38e25e5b
          |   |   |   |  |       |   |   |   ['a', 'b'] as Set
          |   |   |   |  |       |   |   ['a', 'b'] as String[]
          |   |   |   |  |       |   ['a', 'b']
          |   |   |   |  |       [1, 2, 3, 4]
          |   |   |   |  {toString() == null}  foo$1@4b10c0df
          |   |   |   {x}  StringBuffer@38e696f9
          |   |   '''a
          |   |    'b'''
          |   'a \'b'
          false


So for collection types I preserve printing of the literal, but add
the type unless it is the default type, and for Objects I print the
pattern'{<toString()>}  <classname>@<hashHex>' (unless that's what
toString() prints), and I remove the packagename of classes in the
packages imported by default in groovy (java.lang, java.util, ...).
String literals are hyphenated and escaped (also as map keys), when
they contain newlines I use multiline Strings (escaping only triple
hyphens, not shown in example).

I am not quite sure about how to best escape triple-hyphens within
multiline Strings, I decided to add a backslash to all of the hyphens,
even if it might be sufficient to escape only the third each time or
so.

I believe the additional information to be noisy indeed, but that the
benefit outweights that price. But it is a matter of personal
preference I guess, so I am not sure whether this will go into Groovy
or not.

On Tue, Aug 25, 2015 at 9:48 PM, Thibault Kruse
<tibokruse@googlemail.com> wrote:
> I had not considered the case of other classes and their toString() method.
> And indeed I think it might also be good to output the class and
> hashId in addition to toString in such cases. Like this:
>
> assert new Foo() == "aa"
>        |         |
>        |        false
>       {aa} com.package.foo.Foo@1sd2d23sc
>
> In that case I would also not escape the output of toString().
>
> I will try out several variants, I am not yet sure about the best way
> to print Objects.
>
>
> On Tue, Aug 25, 2015 at 8:58 PM, Jamie Echlin <jamie.echlin@gmail.com> wrote:
>> Fair enough. Maybe I have a better real-world example that seems to trip up
>> people that I "know":
>>
>> class Foo { String toString() {"aa"} }
>> assert new Foo() == "aa"
>>
>> assert new Foo() == "aa"
>>        |         |
>>        aa        false
>>
>> Taking your proposal, '"aa" as Foo' is not valid, so I'd rather see output
>> like '"aa" (Foo)'. But that would be noisy, so ideally I'd like to see that
>> only if the output is counter-intuitive, although clearly I have no idea if
>> that's feasible.
>>
>> I think I disagree that the format for the entire results need be the same
>> as that for partial results.
>>
>> In the example above, better formatting for strings would possibly make it
>> even less intuitive.
>>
>>
>>

Mime
View raw message