> Yes, javascript-based flow is the recommended way, javaflow is stil > "officially" considered experimental (but AFAIK very usable and stable > already).
huh, alright, anyone cares to post some pros & cons of those two flow languages (javascript flow vs javaflow)? > For unit testing flowscript, I'd use an HTTP-based method, which allows > you to test the full request processing chain "in situ". the problem in that is that it's not real unit testing, unit testing should be done *in isolation*, this HTTP based testing is closer to integration testing or functional testing, that is also cool but it doesn't give the scope useful for test-driven development. > You're right that unit testing flowscript directly could be useful, but > I don't think we have examples of doing it in Cocoon currently. If > you'd like to try and create something for this, there are several > examples of JUnit testing of Cocoon components in the codebase, which > should be a good base to start from. I'll research that possibility > To test my custom Cocoon components in their environment, I've been > using a custom JUnitGenerator, which executes JUnit tests in the same > environment than my production components (database configs etc) and > outputs the results in XML. I forgot to mention this when we talked > last week after your comment on my weblog. I suppose that this approach lacks isolation as well, anyway I'll be happy to take a look at it if you could publish the code somewhere > It's fairly rough and probably not general, but if you'd like to > improve it I could post the code on the wiki as an example. I don't > think it would help much about flowscript testing but it could give you > some ideas. I'll could give it a try -- Wojtek Biela --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
