Stephen Haberman has posted comments on this change.
Change subject: Add interfaces for widgets.
......................................................................
Patch Set 7:
Replying to Goktug...
consistent naming convention throughout the SDKs
Agreed, of course. I see what you mean with the asXXX methods.
However, personally, I thought "IsXXX" just meant "we really wanted to name
this interface just 'XXX', but that name was already taken by the concrete
class, which we can't rename, so we're adding the 'Is' prefix instead".
I am open to suggestions, but personally think IsAbsolutePanel/etc. is a
pretty good fit.
Looking at the size of this change and thinking of its implications, we
need a very good justification for it
Well, it is big, yes, but I assert it's actually pretty simple. No
semantics or logic are changing, it's just laying some interfaces over
things.
see a demonstration why mocking options out there [...] and see if we can
fix the problem without this mess
Well, I read the github page for gwt-mockito, and I believe we have
different opinions on what constitutes a "mess" :-).
Personally, I think just adding interfaces is a much more straight forward
approach than hacking around with classloaders/etc.
That said, I would be fine adopting a non-IsXXX variation of my approach if
it was technically viable; however, AFAIK, it is not.
As a distilled/simplified example, what I do is, roughly:
IsElement e;
// if in prod
e = new Element()
// otherwise in tests
e = new StubElement();
// now presenter uses e for business logic
e.setInnerHTML("asdf")
// and the test asserts that it worked
assertThat(e.getInnerHTML(), is("asdf"))
This same pattern applies for all of the widgets, e.g. IsAbsolutePanel/etc.
If I were to use gwt-mockito in the above snippet to replace "IsElement"
with just "Element", I would still need my "class StubElement extends
Element" to be able to override and implement stub logic for all of
Element's methods.
Which, given it's a JSO and has final methods, would not be possible.
So, basically, stubs cannot rely on as much classloader magic as mocks can.
However, I do not believe this means stubs are an unacceptable way of
testing--they just typically require interfaces.
That said, I would assert that the whole notion of having JRE-only tests
(that sometimes talk to real UI widgets and sometimes fake UI widgets)
means that, really, widgets & friends should have had interfaces from the
beginning.
Interfaces are the canonical way in Java to say "program against this API,
and there will be multiple implementations".
I don't think this is very provocative.
--
To view, visit https://gwt-review.googlesource.com/3231
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: Ibd17162d37e367720829bcdaf9a350e446c833b9
Gerrit-PatchSet: 7
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman <[email protected]>
Gerrit-Reviewer: Colin Alworth <[email protected]>
Gerrit-Reviewer: Daniel Kurka <[email protected]>
Gerrit-Reviewer: Goktug Gokdogan <[email protected]>
Gerrit-Reviewer: Leeroy Jenkins <[email protected]>
Gerrit-Reviewer: Stephen Haberman <[email protected]>
Gerrit-Reviewer: Thomas Broyer <[email protected]>
Gerrit-HasComments: No
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
