Tests don´t work properly when tested code uses custom GWT deferred binding

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create code using deferred binding for some custom compile-time code 
generation
eg.:
<generate-with class="mtpackage.myClass">
    <when-type-assignable class="mypackage.myInterface" />
</generate-with>

2. Try to test it.

What is the expected output? What do you see instead?
It was expected that I could test my code, but custom gwt deferred binding does 
not seem to be supported by the gwt-test-utils. 

What version of the product are you using? On what operating system?
I'm using gwt-test-utils-0.30-snapshot, gwt-2.3.0, Eclipse Helios and Ubuntu 
10.10

Please provide any additional information below.
What I am trying to accomplish is to modify simple beans at compile-time, 
putting additional code in some setter methods, so I can monitor its usage and 
have listeners notified whenever this methods are called.

I want to monitor this bean classes so that any changes to the model can notify 
interested listeners, updating the UI and some other client services.

Although I was able to make my POC work I am not able to test it using 
gwt-test-utils. I want to know if there are any plans to support it, and if so, 
when would it be available. 

I know that custom deferred binding is an unusual and advanced GWT usage case, 
and I really appreciate your framework and it is completely understandable if 
this framework does not envision to support it. 

Thanks in advance,
Jaime Schettini

Original issue reported on code.google.com by jaime.sc...@gmail.com on 13 Jun 2011 at 6:48

[GoogleCodeExporter]

I must admit that I've never used custom deferred binding myself. I'll read the 
corresponding documentation 
(http://code.google.com/intl/fr-FR/webtoolkit/doc/latest/DevGuideCodingBasicsDef
erred.html) to figured out how gwt-test-utils could support it.

It would be nice if you could provide the source code of your POC not to miss 
anything.

Original comment by gael.laz...@gmail.com on 14 Jun 2011 at 6:44

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

The <replace-with> tag in .ui.xml files could be easy to support, but not 
<generate-with>.

In fact, Generator relies on some part of the GWT API (which deal with java 
class metadata : JClassType, TypeOracle) which is totally bypassed by 
gwt-test-utils.

Despite it does not relies on this API, gwt-test-utils could detect your 
declared <generate-with> tag, and indicate developpers they should add a custom 
GwtCreateHandler or mock object for the <when-type-assignable> value because 
gwt-test-utils does not support deferred binding <generate-with> mechanism. 

Original comment by gael.laz...@gmail.com on 4 Jul 2011 at 8:36

[GoogleCodeExporter]

Original comment by gael.laz...@gmail.com on 19 Jul 2011 at 5:56

• Changed state: New

[GoogleCodeExporter]

Thanks for checking this, man. Sorry for the late reply.

Original comment by jaime.sc...@oncast.com.br on 18 Aug 2011 at 5:08

[GoogleCodeExporter]

Original comment by gael.laz...@gmail.com on 28 Aug 2011 at 1:24

• Changed state: Started

[GoogleCodeExporter]

I finally added some basic support for custom deferred binding :

- for replace-with declaration, gwt-test-utils will check for the default 
replacewith class ( = with no 'when-property-is' subchild) and will try to 
instanciate the class with a new GWT.create(..) instruction

- for generate-with declaration, if no custom GwtCreateHandler has been added, 
gwt-test-utils will throw a GwtTestConfigurationException which tells GWT 
Generator API is not supported, so developper will have to declare their own 
GwtCreateHandler or @Mock an instance of the class.

Can anyone verifed it works and give me some feedback ?

Original comment by gael.laz...@gmail.com on 28 Aug 2011 at 4:13

• Changed state: Fixed

[GoogleCodeExporter]

I can verify both changes to "work for us". 

- 'generate-with' raises an exception, if no handler is defined for the defined 
type, and stays silent, if a handler indeed does provide some instance.
- 'replace-with' creates an instance of the replacement class (I did no 
negative checks here).

I wonder, why the 'when-property-is' stays unsupported. Should not be too 
complex to handle, given a possibility to pre-set property values from within a 
test. It does not necessarily have to support the 'set-property' feature as 
well, I think.

Original comment by stefan.s...@googlemail.com on 29 Aug 2011 at 9:39

[GoogleCodeExporter]

You're right, it would be easy.
A GwtTest.setProperty(name, value) method should be comprehensive.

For example, to tell gwt-test-utils we want to run a test with Mozilla :

@Before 
public void setupProperties() {

   this.setProperty("user.agent", "gecko");
}

I've reopen the issue and will add this feature in the next snapshot, stay 
tuned ;-)

Original comment by gael.laz...@gmail.com on 29 Aug 2011 at 9:48

• Changed state: Started

[GoogleCodeExporter]

I've just deploy new snapshots (0.33-SNAPSHOT, 0.22.4-SNAPSHOT, 
0.25.4-SNAPSHOT, 0.28.7-SNAPSHOT) with a better implementation for 
<replace-with> deferred binding.

To set a Browser property, just call at the beginning of your test :

Browser.setProperty("user.agent", "gecko");

Note that all Browser's properties are reseted between each unit test.

Could you please try it and give me some feedback ?

Original comment by gael.laz...@gmail.com on 2 Sep 2011 at 5:37

[GoogleCodeExporter]

Setting properties works well for me. Nicely done.

Using: gwt-test-utils-0.28.7-20110907.070135-2.jar

Original comment by stefan.s...@googlemail.com on 8 Sep 2011 at 7:48

[GoogleCodeExporter]

Thanks !

Original comment by gael.laz...@gmail.com on 8 Sep 2011 at 7:58

• Changed state: Verified

[GoogleCodeExporter]

Gael, I did some experiments with Generators. Only to get things started it 
takes about 15 seconds (and throw exception at the end :) ). While the use of 
standard implementation is not feasible (loads all the classes, analyses and 
builds an AST - Abstract Syntax Tree, etc), I think it's definitely an option 
to provide some simple (even stub?) GeneratorContext/Context implementations, 
that would work for 90% of cases (I know RemoteService generator is heavily 
dependent on the types provided through its context, i.e). 

All these would affect the 'generate-with' clause.

Original comment by alex.dob...@gmail.com on 13 Sep 2011 at 3:17

[GoogleCodeExporter]

Gael, I did some experiments with Generators. Only to get things started it 
takes about 15 seconds (and throw exception at the end :) ). While the use of 
standard implementation is not feasible (loads all the classes, analyses and 
builds an AST - Abstract Syntax Tree, etc), I think it's definitely an option 
to provide some simple (even stub?) GeneratorContext/Context implementations, 
that would work for 90% of cases (I know RemoteService generator is heavily 
dependent on the types provided through its context, i.e). 

All these would affect the 'generate-with' clause.

Original comment by alex.dob...@gmail.com on 13 Sep 2011 at 3:17