[Windmill-dev] Tests in native JavaScript

[Matthew Eernisse]

Thanks for the detailed and thoughtful response. Responses inline below.

Mikeal Rogers wrote:
> The only issue with using the plugin system for that is if the amount of 
> tests you're writing this way gets too large it would be very difficult 
> to maintain. 

Right -- I think the scenario of people wanting to do tests in JS with 
the app loaded in the browser will be common enough that "write a plugin 
for all your tests" might not be a tenable approach.

> Since the JSUnit tests can have all the js code in the IDE we won't have 
> anything loaded in the browser when we run the tests. We could provide 
> an extension to unittest object that we will need to implement for the 
> unittest code ( in the current cosmo JSUnit tests this object is 'jum' ) 
> that is a wrapper object for the controller API. So;
> 
> jum.assertEquals("new", delta.getProperty("displayName"));
> jum.assertFalse(delta.getProperty("body") == undefined);
> jum.controller.open(url)
> jum.controller.click(id='blah')

This seems fairly close to what I was thinking about for the 
non-declarative option -- using JS code to do the UI manipluation that 
the current JSON or Python tests do.

I was thinking we could use the existing JSON syntax pretty much as-is, 
since it's already valid JS, and the controller already knows how to 
consume it. No need to invent yet another DSL for manipulating the UI. 
So, something like:

var arr = [
{"method": "type", "params": {"id" : "goToDateInput", "text": 
"05/08/2002"}},
{"method": "click", "params": {"jsid" : "{$miniCalGotoButton}"}},
{"method": "wait", "params": {"milliseconds" : 5000}}
];

jum.controller.doSomeUiStuff(arr);

> The largest limitation of all this is that you can't stager a regular 
> windmill test and a JSUnit test one after another. They follow 
> completely different workflows and would be loaded in to the service 
> very differently.

To me the JSUnit thing is actually kind of anciallary. To me the most 
important thing is just having a sane, structured way to write Windmill 
tests in JavaScript.

I can see an argument for wanting to go API-compatible (or mostly so) 
with JSUnit for the native JS tests -- both because people are familiar 
with it, and because it opens the door to the idea of sharing some tests 
between Windmill and JSUnit.

On the other hand, if it's going to sidetrack seriously the process of 
getting native JS tests working in Windmill, maybe we ought to avoid 
opening the JSUnit can of worms.

If doing something like writing plugins is the most expedient way to get 
it started, then that's cool -- but my suspicion is that it's not a good 
long-term solution, and I'd like to avoid rework later.

Thoughts?


Matthew