[Webtest] Someone really attribute value of setcheckbox?

Dierk Koenig webtest@lists.canoo.com
Wed, 7 Jul 2004 12:31:42 +0200

> - a wrongly typed value for the type attribute would only be 
> detected when the step is running. It can't be detected by 
> ant before running the script

I agree.

> - the java code of the step would need a switch on the type value 
> as for instance setting a text field requires 
> different code as setting a select for instance


These two points speak against the type="" issue.

> What about providing 2 task definition files. The one with the 
> old steps and the other one with the new steps?

This would be the proper way to switch implementations.

>From a more abstract view, we change behaviour of a public api.
This is always tricky to do.
1) One alternative is changing the behaviour _without_ changing
the api (method signatures or step names in our case).
+ This puts no burden of change to the user in case that
  everything is backward compatible. He may not even notice the change.
- Any break of backward compatibility is really bad for the user.
  He has no chance of mix-and-match between old and new
  functionality. He gets no technical feedback (compiler or ant) that
  something has changed.
2) Only provide a the changed api.
+ User is aware of the changes.
- He has to change everything right now.
3) Additionally provide the new api, mark the old one deprecated.
+ User is aware of the changes.
+ User can choose between old or new api.
+ User can take his time for migration as long as the deprecation
  period is running.
- Api becomes wider (during the deprecation period).

I prefer 3) in the general case and 1) only if there is very low
risk of breaking the backward compatibilty .