[Windmill-dev] Windmill 0.4 Roundup

[Mikeal Rogers]

I think a very workable goal for this release should be to have a  
javascript equivalent of

http://windmill.osafoundation.org/trac/browser/windmill/trunk/test/test_live/test_unit.py

We can hold off for the moment on testing the failure cases, and the  
waits cases.

For now, mde can write these tests without worrying about how to run  
them alongside the other windmill tests. That work can be done in  
parallel by Adam and myself, outlined somewhat below in my previous  
response.

If all goes well we should have the js framework integrated as a first  
class citizen and a good start on a unittest suite for this release.  
Making the js tests executable from functest is a requirement for this  
release, and is also what we will use to run these tests alongside the  
rest of our unittests.

I'd also like to mention that the test run shouldn't take more than  
one minute. I'd like to see the total run time for our unittests stay  
fairly low until we have a continuous integration system setup for  
windmill.

-Mikeal

On Jan 29, 2008, at January 29, 20081:36 PM, Adam Christian wrote:

> That's a good question, this may take some tinkering to come up with  
> a thorough way to test that functionality.. as soon as I have a  
> minute I will sit down and see if I can come up with something.
>
> Do you guys have a set of JS Framework features you would like to  
> start with?
>
> Adam
>
> On Jan 29, 2008, at 10:26 AM, Mikeal Rogers wrote:
>
>>> Not sure how you'd write unit tests for filter/phase limiting, as  
>>> they're attributes of the *test run*, not anything in the tests  
>>> themselves. Their value is during dev and debugging, not during  
>>> actual testing. Anybody have any ideas how we could do tests for  
>>> that?
>>
>> We do need to work out the semantic for you informing the backend  
>> of your whole test run status at the end of the test run.
>>
>> The results object you give to the backend will have the list of  
>> tests run.
>>
>> I'll be creating an XMLRPC method for executing the js framework.  
>> We can call that with various filter/phase limiting and check the  
>> test run result objects in pure Python.
>>
>> For now tho, we need unittests for all the jsTest methods, just  
>> like we have the vanilla windmill API. For now we can just focus on  
>> tests that return true, we can work out a way to test failures and  
>> waits later using something along the lines of what i outlined for  
>> the filter/phase limiting.
>>
>> We don't need 100% of the features covering in unittests before we  
>> release, i just want the first run of them in and we can improve/ 
>> expand them later. As it stands we have zero, we definitely need  
>> more than zero before we release.
>>
>>>
>>>
>>> I think Adam would be the one to ask about calling new methods on  
>>> test-run completion. Adam, any clue about that?
>>
>> Whoever wrote the code that calls report_without_resolve() would be  
>> the most likely person to do this work as well, whoever that is.
>>
>> -Mikeal
>> _______________________________________________
>> Windmill-dev mailing list
>> Windmill-dev at osafoundation.org
>> http://lists.osafoundation.org/mailman/listinfo/windmill-dev
>
> _______________________________________________
> Windmill-dev mailing list
> Windmill-dev at osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/windmill-dev