17 messages in com.canoo.lists.webtest[Webtest] [dev] refactoring| From | Sent On | Attachments |
|---|---|---|
| Marc Guillemot | 03 Aug 2005 02:16 | |
| Dierk Koenig | 03 Aug 2005 05:21 | |
| Dierk Koenig | 03 Aug 2005 06:21 | |
| Marc Guillemot | 03 Aug 2005 06:36 | |
| Marc Guillemot | 04 Aug 2005 01:32 | |
| Dierk Koenig | 04 Aug 2005 02:02 | |
| Marc Guillemot | 04 Aug 2005 03:20 | |
| Dierk Koenig | 04 Aug 2005 05:33 | |
| Paul King | 04 Aug 2005 06:22 | |
| Denis N. Antonioli | 04 Aug 2005 06:35 | |
| Marc Guillemot | 04 Aug 2005 07:00 | |
| Dierk Koenig | 04 Aug 2005 07:25 | |
| Dierk Koenig | 04 Aug 2005 07:34 | |
| Paul King | 04 Aug 2005 07:54 | |
| Paul King | 04 Aug 2005 08:08 | |
| Marc Guillemot | 04 Aug 2005 10:12 | |
| Denis N. Antonioli | 25 Aug 2005 12:35 |
| Subject: | [Webtest] [dev] refactoring![]() |
|---|---|
| From: | Marc Guillemot (mgui...@yahoo.fr) |
| Date: | 08/03/2005 02:16:42 AM |
| List: | com.canoo.lists.webtest |
Hi,
I was asking myself about the utility of some classes: Setup TearDown WebTestSpec Engine Context
Indeed
- WebTestSpec just get filled with the information (ie the nested tasks)
gathered from WebtestTask (former
TestSpecificationTask) => what does this artificial separation bring? I can
imagine that the idea has been to try
decouple from ant but as long as all nested steps are ant tasks as well, I don't
see the need.
- Engine just executes the steps therefore it's executeSteps should just be a
method of WebtestTask
- Setup and TearDown are artificially created steps. I think that their job
should be in WebtestTask as well, what would
allow to reduce the visibility/access of some member variables
- Context just holds informations for the running steps and could be merged in
the WebtestTask. Indeed when we need to
look at the current step number this is the current step number of the webtest
rather than of the context of the
webtest. Same thing for last response.
What do you think?
Notes to the committers:
1- please try not to reinvent the wheel! The Jakarta libs used contain many
utility methods that are surely better
tested as the one we may write ourself. Before writing a new utility, just look
if it doesn't already exist
2- please write javadoc to explain your code!
3- mail me if I don't respect the 2 previous points ;-)
Marc.




