[Windmill-dev] Assert param names

[Adam Christian]

What we currently have is:

windmill.registry.methods['asserts.assertProperty'] = {'locator':  
true, 'option': 'validator' };
windmill.registry.methods['asserts.assertText']     = {'locator':  
true, 'option': 'validator' };
windmill.registry.methods['asserts.assertValue']    = {'locator':  
true, 'option': 'validator' };
windmill.registry.methods['asserts.assertChecked']  = {'locator':  
true, 'option': false };
windmill.registry.methods['asserts.assertSelected'] = {'locator':  
true, 'option': 'validator' } ;

We may want to change validator for each of those to something that  
makes a little more sense.


On Nov 16, 2007, at 3:52 PM, Mikeal Rogers wrote:

>
> On Nov 16, 2007, at November 16, 20073:41 PM, Adam Christian wrote:
>
>> Essentially going from:
>> {"params": {"validator": "blah", "id": "header"}, "method":  
>> "asserts.assertText"}
>>
>> to:
>> {"params": {"text": "blah", "id": "header"}, "method":  
>> "asserts.assertText"}
>>
>
> I do like this more than the old API, but having assertText take a  
> "text" param seems a little redundant. You said something about  
> assertValue at one point.
>
> Could we move to something like asserts.assertValue({"text":"asdf",  
> "id":"header"}).
>
> Are there other functions we could replace with params like this in  
> assertValue?
>
> Also, in this example it's just id="header", this takes all the  
> standard locator stuff doesn't it?
>
> I like where this is going and I think your example is cleaner. Once  
> we agree on a strategy we can get this in to the 0.3 release. We  
> can't change any of the external API's in an 0.2.x release.
>
> -Mikeal
>
>> I think it's a bit more intuitive, nicer for code readability, but  
>> most importantly I think it's what users are used to when switching  
>> from other test frameworks.
>>
>> Im not married to the idea, just throwing it out there.
>>
>> Adam
>