Extending the as(Description) method...

2 views
Skip to first unread message

Ed

unread,
Nov 27, 2009, 1:18:43 PM11/27/09
to easytesting
Hellu again,

I am sorry for spaming your forum soo much from out of nothing :(...

Anyway: I looked at your as(..) method and would like to have it
extended (I added it to the issue tracker with a link to this post,
but I think it's good that people give their opinion before it's
implemented).

Before implementing it, you might first want to have a look at my
previous post about the Generics issue:
http://groups.google.com/group/easytesting/browse_thread/thread/898b9de8448c1b0e#

If that one is solved, this one is solved easy and fast as only small
modifications to the super class is needed.
I started making modifications to the current source, but it's a bit
too much to just do it quickly :(...

Anyway: I would love to extend the as(Description) method such that we
can easily submit objects that are logged in the error message.
This is possible through an Descriptor implementation, which is great
of course, but ti's not very user friendly.
In case of using the Description interface, you should get something
like this:
assertThat("bla").as(new ObjectsDescription("my objects", obj1, objs2,
objs3)).isEqualTo("bla1");

I am looking for something like this:
as(String message, String description1, Object obj1);
as(String message, String description1, Object obj1, String
description2, Object obj2);
as(String message, String description1, Object obj1, String
description2, Object obj2, String description3, Object obj3);
as(String message, String description1, Object obj1, String
description2, Object obj2, String description3, Object obj3, String
description4, Object obj4);
as(String message, Object...objs);
as(String message, String[] descriptions, Object...objs);

So the call would look for nice:
assertThat("bla").as("my objects", obj1, objs2, objs3).isEqualTo
("bla1");
This might not look as much of a "win" but if you do many of these
asserts, it will. Said that, the modifications are small and simple...
And I think you should hide the Presentation of the error message and
not mix them with any logic testing flow.... and repeat defining the
presentation again and again... I hope I got you confinced :)

So the output would be something like:
My error message:
Description1= ToString output of object1
Description2= ToString output of object2
Description3= ToString output of object3
...

Or if not descriptions are submitted:
My Error message:
obj-1= ToString output of object1
obj-2= ToString output of object2
obj-3= ToString output of object3
...

I would be nice to be able to set your own output formatter through a
constructor or static method....

I already made an ObjectsDescription, see below, but the as() method
changes results in a lot of modifications due to the lack of using the
Generics... so then I stopped :(.... I hope to get it will be
implemented soon...

----
public final class ObjectsDescription extends BasicDescription {

private final String[] descriptions;

private final Object[] objs;

public ObjectsDescription(String message, String[] descriptions,
Object[] objs) {
super(message);
this.descriptions = descriptions;
this.objs = objs;
}

@Override
public String value() {
return UtilsString.createLogString(super.value(), descriptions,
objs).toString();
}

Alex Ruiz

unread,
Nov 27, 2009, 2:31:48 PM11/27/09
to easyt...@googlegroups.com
Hi Ed,

Now I got a better understanding of your proposal. I can see it's useful, but I need a little time to think about it, just to make sure it the API doesn't get too complicated.

Thanks!
-Alex


--

You received this message because you are subscribed to the Google Groups "easytesting" group.
To post to this group, send email to easyt...@googlegroups.com.
To unsubscribe from this group, send email to easytesting...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/easytesting?hl=en.



Ed

unread,
Nov 27, 2009, 2:43:57 PM11/27/09
to easytesting
I understand completely...
I think the question would be: what is the scope of your API?
But I think it's desirable to be able to change the error presentation
in an easy user friendly way separate from the assert calls.....
Nice challenge... -> good luck and have a nice weekend :)
In the meantime I use a factory method to create my
ObjectsDescription.
BTW: I don't see the need for BasicDescription being final, such that
I can extend from it...

Ted Young

unread,
Nov 27, 2009, 3:05:45 PM11/27/09
to easyt...@googlegroups.com
I had also been thinking along these lines (something like this is in my unsubmitted code, waiting for some free time to complete). A description strategy seemed to capture the needs, as least from what I can see. For example:

assertThat(something)
  .as(myDescriptionStrategy(message, value1, value2, object)
  .isGood();

Where

public Description myDescriptionStrategy(String message, Object...) {
  // do formatting
  return ...
}

Thoughts?

;ted

Ed

unread,
Nov 27, 2009, 3:11:56 PM11/27/09
to easytesting
I like the idea...

Basically fest offers you the log freedom through the Decription class
and through static method (just like assertThat) you can set up you
logging lously coupled...
Just like "assertThat" you would get something like "logThat" :)...

+1

Alex Ruiz

unread,
Nov 27, 2009, 5:51:19 PM11/27/09
to easyt...@googlegroups.com
If I understood correctly, I agree with Ted. Let's leave logging in an implementation of Description. I've been thinking about this for a few hours and, IMHO, I think having logging *built-in* in the assertions would make it easier to write them (for the ones interested in logging,) but it would make it more difficult to read.

Ed, I'll make BasicDescription non-final. Can you please file a bug for this? :)

Thanks!
-Alex

Ed

unread,
Nov 27, 2009, 5:56:40 PM11/27/09
to easytesting
Done

On Nov 27, 11:51 pm, Alex Ruiz <alex.ruiz...@gmail.com> wrote:
> If I understood correctly, I agree with Ted. Let's leave logging in an
> implementation of Description. I've been thinking about this for a few hours
> and, IMHO, I think having logging *built-in* in the assertions would make it
> easier to write them (for the ones interested in logging,) but it would make
> it more difficult to read.
>
> Ed, I'll make BasicDescription non-final. Can you please file a bug for
> this? :)
>
> Thanks!
> -Alex
>
> On Fri, Nov 27, 2009 at 12:11 PM, Ed <post2edb...@gmail.com> wrote:
> > I like the idea...
>
> > Basically fest offers you the log freedom through the Decription class
> > and through static method (just like assertThat) you can set up you
> > logging lously coupled...
> > Just like "assertThat" you would get something like "logThat" :)...
>
> > +1
>
> > --
>
> > You received this message because you are subscribed to the Google Groups
> > "easytesting" group.
> > To post to this group, send email to easyt...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > easytesting...@googlegroups.com<easytesting%2Bunsu...@googlegroups.com>
> > .

Alex Ruiz

unread,
Nov 27, 2009, 5:57:21 PM11/27/09
to easyt...@googlegroups.com
Thanks Ed! :)

Cheers,
-Alex

To unsubscribe from this group, send email to easytesting...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages