-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gwtmockito + gwtquery #31
Comments
This seems like it might be hard - GwtQuery is naturally very DOM-centric, so it's not really going to be possible to emulate much of the interesting behavior in Java which basically rewriting an entire browser. It wouldn't be too hard to stub out methods so that it doesn't run into exceptions when you execute $() from within a test, but I'm not sure this would be useful. What would you want a test leveraging GwtMockito and GwtQuery to look like? |
@ekuefler I agree with you that GwtQuery is naturally very DOM-centric and plus they are static methods call in general where we cannot even verify. Unless we can make GwtMockito to work together with PowerMockito where we can delegate to use GwtMockitoTestRunner, which currently is not possible as both PowerMockito and GwtMockito's classloader modifcation(not sure if i got the terms correct) interferes with each other. However that being said, the problem that is causing GwtMockito tests to fail when there is a Gquery code is due to the infamous JavaScriptObject#cast(). I suppose for now if you can help point out some workaround so that we can stub out all the GQuery objects to be a mock, then we will be okay, just like how you get around the GWT.create issue. |
Which class contains the call to JSO.cast()? A stack trace might be helpful. It's possible you can work around the problem in your test by annotating the test with |
In GQuery.java there is cast happening there. If we tried to stub GQuery, we will fail eventually due to the following limitation on mockito for "final":
|
Looks like the code you're referencing is from https://github.com/gwtquery/gwtquery/blob/master/gwtquery-core/src/main/java/com/google/gwt/query/client/plugins/Effects.java#L103, which is indeed doing a lot with statics, finals, and javascript casts that are going to interfere with mocking. Have you tried annotating the test with |
@ekuefler: Ran recently into this issue and tried to add
I also tried to add |
One hurdle that I can't seem to get over when trying to unit test views is I often use gwtquery. Unfortunately, using gwtquery makes for untestable views.
Do you think a collaboration between you and @jDramaix would be possible in order to make gwtquery play nice with gwtmockito? gwtquery seems like a very popular library in the GWT world, so it would make sense to allow it within a unit test context.
Thanks a lot for your great work :)
The text was updated successfully, but these errors were encountered: