[Windmill-dev] js framework "exit on done" work

[Adam Christian]

Your functional need for the js_test_run_final makes a lot of sense,  
im +1 lets go for it.

To clarify, the other methods I was thinking a simple action someone  
could put in their tests (optionally) to update the IDE when the  
tests were done running so a user would know.

For example the first action in a whole run of windmill tests could  
be the rest_run_start which would tell the IDE we are starting the  
cosmo0.8tests, when the suite is done, the last action in the  
windmill teardown would be test_run_final and the IDE could change  
the status to "cosmo0.8tests done." Simply for some better user  
status feedback, would be nice when im running these all day long to  
be able to just glance at the IDE and know it's finished.. obviously  
more important if you run with the shell option and want to do some  
debugging or state checking etc when they are finished running.

Adam

On Oct 22, 2007, at 7:14 PM, Mikeal Rogers wrote:

> I don't know what these methods mean?
>
> js_test_run_final is a special case to tell the service that the  
> jsTest framework is complete so a framework can query the Service  
> and get state in order to move along or kill the browser.
>
> I don't understand what test_run_final is suppose to be, and if  
> it's a service method I don't know what it's use is or who calls  
> it, if it's a shell method I'm equally confused. Not being  
> camelCase I'm assuming it's not a callback that is handed off to  
> the IDE.
>
> Very very confused.
>
> -Mikeal
>
> On Oct 22, 2007, at 7:06 PM, Adam Christian wrote:
>
>> So if I wanted to run the whole suite of ide tests and i didn't  
>> want a suite to be just a single file, we may want to following:
>>
>> test_run_start
>> test_run_final
>> js_test_run_start
>> js_test_run_final
>>
>> That way when any set of tests starts and finishes we know that  
>> and can notify the user accordingly.
>>
>> Adam
>>
>> On Oct 22, 2007, at 6:46 PM, Matthew Eernisse wrote:
>>
>>> +1
>>>
>>> I actually remember asking about this before -- it's a pretty  
>>> standard thing to want to know when an entire suite has finished.  
>>> Of course that would require that we have some kind of a larger  
>>> concept of a 'suite.'
>>>
>>> But it would be nice to be able to call a big blob of tests, and  
>>> then get some kind of summary when the entire thing is done.
>>>
>>>
>>> Matthew
>>>
>>> Adam Christian wrote:
>>>> This sounds fine to me, I was also thinking that this might not  
>>>> be such a bad idea for the non js tests.. that way the IDE can  
>>>> actually display some output like.. "Suite finished running" etc  
>>>> so people don't have to guess on the state.. ideas?
>>>> Adam
>>>> On Oct 22, 2007, at 2:50 PM, Mikeal Rogers wrote:
>>>>> Trying to get the js based tests hooked up I just noticed some  
>>>>> problems.
>>>>>
>>>>> 1) The Service has no idea when the jstests are finished. I can  
>>>>> guess by waiting for the IDE to call next_action() but this is  
>>>>> problematic.
>>>>> 2) If we just add a simple "I'm done" method to the Service it  
>>>>> then has no way to differentiate between multiple js test runs.
>>>>>
>>>>> What I propose is to make some additions to both interfaces.
>>>>>
>>>>> Currently commands.jsTests only takes one argument, "tests"  
>>>>> which is a list of the js files it's recursively parsed from  
>>>>> the given directory. I'd like it to take another argument,  
>>>>> "uuid" which will be a standard UUID for the test run.
>>>>>
>>>>> At the end of that test run, the js framework should call a new  
>>>>> method in the Service called "js_test_run_final" with params  
>>>>> "uuid" and "results" (a serialized list of the test results --  
>>>>> i believe you're already keeping this somewhere).
>>>>>
>>>>> This way the Service can make multiple test runs and people can  
>>>>> query the server to see the status of any test run. This work  
>>>>> can also be leveraged once we go multi-client with minimal  
>>>>> changes.
>>>>>
>>>>> The Service will be implementing additional methods so that  
>>>>> remote xml/json-rpc clients can start js test runs and get the  
>>>>> results from the Service.
>>>>>
>>>>> If anyone else would like to add more methods or options to the  
>>>>> js test workflow now would be a good time. Is there anything  
>>>>> else going on over in JavaScript land that the Service might  
>>>>> was to be notified of?
>>>>>
>>>>> -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
>>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> Windmill-dev mailing list
> Windmill-dev at osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/windmill-dev