Hi.
Jean-Sebastien Delfino wrote:
I'd imagine the following:
- I (Mr Tester) select a component in my assembly and click Test
- I see a list of services offered by the component, can select a
service / business interface / business operations, see the
inputs/outputs, can use a form to fill the input data and invoke the
business operation.
- I set a breakpoint in my component implementation (if it's written
in a programming language supported by my debugger). I hit my
breakpoint when the business method is invoked.
- I see a property sheet allowing me to configure the component
properties.
- I select references on the component and stub them, i.e. first
inspect what's flowing through them, then I simulate the target
component, see the input data, use a form to return the output data.
- I inspect the component instances in scope (e.g. for a
request-scoped or conversation-scoped component I can see what
instances are active).
- Finally, because life in an XML world is unfair, and most of my
problems are usually Java/XML data transformation problems, I can
select a binding on my service or reference, observe the (XML) traffic
and check that my business data flows nicely over the binding when I
invoke the business operation.
I may have missed a few important scenarios, but that's a start.
I think we can also do interesting things in terms of automated unit,
function, integration tests (like generate test cases for your
automated build) but that's a different discussion I guess.
Thoughts?
I was suggested a similar proposal some weeks ago, with breakpoints and
so on (just as we can test Web Services in the WTP Eclipse project).
I agree that's interesting and that it would be useful for developers to
help them. This is the kind of thing a developer would use when he makes
some developments / changes and he wants to test them, by hand, and
debug his code if necessary.
When I said test, I was rather thinking to the last points you mentioned
(unit test, integration, iterative process... a more global vision of
the test). But maybe these aspects are more relevant from a methodology
point of view rather than from a tooling point of view, and that Maven,
JUnit and other existing tools are enough for these parts.
I will think about your proposal. Maybe such a tool is more useful than
what I was thinking to (whatever it was).
Thanks for your reply, and for the completeness of your scenarios. :)
Regards,
Vincent Zurczak.
--
Vincent Zurczak
EBM WebSourcing
+ 33 (0) 4 38 12 16 77
