On 5/24/06, Holger Hoffstaette <[EMAIL PROTECTED]> wrote:
Hi James, I also looked at BeanFlow and like the basic idea very much, except for the String constants; I guess that's the price of simplicity.
FWIW thats recently been changed to use enums - which we now auto-check that match against valid method names in your class. There's been good feedback lately on improving this further; Eugene commented on annotating the enumerations to declare the transitions declaratively... http://jroller.com/page/eu?entry=coding_workflow_in_java_with and I've just got an email from Brian Goetz I'm digesting where he uses the enums to avoid reflection...
My first idea was, however, to use this for multithreaded test case construction! :) These are always a total bear as you probably know.
Totally! Actually doing distributed integration tests (in multiple threads or JVMs with remoting) is a real big use case for me - its been a constant itch. BTW have you seen the unit test case helpers... http://incubator.apache.org/servicemix/maven/servicemix-beanflow/apidocs/org/apache/servicemix/beanflow/util/package-summary.html You can create a concurrent test case with sync() methods quite easily now... https://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-beanflow/src/test/java/org/apache/servicemix/beanflow/util/ParallelBeanWithSyncs.java
Unfortunately it turns out that only very coarse-grained scenarios could be modeled; for some things I'd need much better control over the timers: exact-start, better scheduling precision, better exception handling/collecting/correlation via the thread group etc. Maybe you have more ideas in that direction?
Agreed. Note that it should be possible to write any kind of precise timer based Activity; the first class we've written, TimedActivity is pretty simple :). We've only just got the basics of BeanFlow going - I'm sure we can add everything you need pretty easily. One of the core features of BeanFlow is to be able to use regular object orientation design strategies (composition, aggregation, inheritence etc) to be able to build up very complex workflows from simple components. So I'm sure we can extend out to tackle the most challenging of orchestrations.
I have an (arguably untypical) test case that really cooks my noodle any time I look at it
LOL! :)
and if BeanFlow could be used to correctly model & execute that it could become an awesome basis for MT test modeling and execution. Drop me a line if you're interested.
I'm definitely interested! Ultimately I'd like to use BeanFlow to create concurrent/distributed integration/system test cases which are pretty complex so I think we're on the same page. -- James ------- http://radio.weblogs.com/0112098/
