[Webtest] Someone really attribute value of setcheckbox?

Marc Guillemot webtest@lists.canoo.com
Wed, 07 Jul 2004 15:57:50 +0200

> 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 .

I agree to the abstract view. The problem with webtest is that the API is to big (too much public methods, the internal 
should be better hidden) and that this API is poorly documented.

Back to the reality, as long as we are using httpunit, we can go following way:
- add "direct" setXXX steps as new steps
- provide these new steps as the standard ones in the task definition file
- provide an alternative task definition files with the old steps as well as the new ones under different names (for 
instance setXXXNew), what would allow to use both simultaneously and progressively migrate
- mark old steps as deprecated and generate messages to alert the user

This would allow new users to use directly the new steps and current users would have time to migrate.