[Webtest] [dev] refactoring

[Marc Guillemot]

Dierk Koenig wrote:
>>>In both cases the extra classes are not for implementation needs but
>>>for communication purposes.
>>
>>what do you mean? For me steps are running in a... webtest, The 
>>Context just represents... the webtest that is running.
> 
> It encapsulates information that a step works upon and passes to
> the next trailing step, e.g. the last retrieved page.
> This is a subtle difference to representing the step itself.
> 
> The class serves an implementation and a communication 
> purpose.

probably to subtle for me ;-(
Context provides a way to get some information about the running webtest but doesn't hide totally the webtest itself as 
many calls to its getTestSpecification() are needed. Therefore we have currently a dirty situation in which some 
information are in Context and other in the test specification without real logic for the sepraration.
As well as each ant Task can directly access the Project or the Target it's nested in, I think that it would be more 
natural to provide such an accessor to WebTest rather than passing it (or the context) to plenty of methods.... [pause] 
I wanted to list how many methods receive Context has parameter and I see (again) that Step has already the context has 
member variable. As this dirty situation is the current status, I really think that it would make sense to go this way 
further: replace doExecute(Context context) with a doExecute().

>>>Context is what steps are supposed to share. 
>>>I would rather like to keep that.
>>>It would also affect a lot of custom steps if we remove that...
>>
>>I can understand that Context removal could imply numerous 
>>changes 
> 
> 
>>(time for a 2.x serie?) 
> 
> not before we have a 1.7 final :-)

and what are we waiting for to make 1.7 final?

>>in custom steps but as far as 
>>I remember you said once, that what matters is just that the 
>>usage in ant files doesn't get broken. Isn't it ;-).
> 
> 
> I cannot remember everything I said once.
> Not breaking the tests as defined in the xml is a must.
> Not breaking custom steps is also valuable. 

but as they are custom steps, we can't be aware of them. I guess that the move from httpunit to htmlunit has broken 
nearly all custom steps.

> We shouldn't do so
> without very good reason.

is a good, well structured, design a good reason?

> Note that changing doExecute(context) to doExecute() would 
> break all steps.

we could imagine to have doExecute() default implementation call doExecute(Context) which would be marked as deprecated.

Marc.