DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=29970>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=29970 [PATCH] inserver junit testing ------- Additional Comments From [EMAIL PROTECTED] 2004-10-25 11:22 ------- In response to Bertrand's remark: The extension proposed in 29970 is more or less complementary to the framework I proposed. In other words, they test things in different areas in the very nice picture you presented at GT2004. The extension that Claas Thiele proposes is useful to test your own components written in Java, in the environment where they will be used, i.e., Avalon/Excalibur. This is a good idea, since testing these components in isolation can be difficult, because your tests have to set up such an environment. My unit-testing framework is meant to be used on pipelines and steps in the pipeline such as XSLT stylesheets. I should have made this clearer in my presentation, but I did not have your picture (which I used to explain this too people who asked me about this). Also, the focus in the projects I have used my framework (which should not be 'my' framework anymore) on was mostly on pipelines, XSLT stylesheets, and a few components written in Java (generators, transformers, ...). Where my presentation and Claas' idea meet is in providing a 'real' environment in which to test components. In my framework, this environment is there because tests run in a 'real' Cocoon server environment. You could use that to unit-test Java components, but only the parts that you can access through a pipeline. Another way to look at this is as a separation of concerns: The Java programmer making buisness logic modules will use JUnit, and 29970 provides a way to mimic the deployment environment. The XSLT programmer would use what I presented yesterday. Both are useful. (I say "XSLT programmer" because I see XSLT as part of a functional programming language, providing primitive functions. Cocoon provides function-composition and application, which allows you to use higher order functions / stylesheets and lots more.) Eventually, I think that different testing methods should be more integrated, using Ant for example, so thee will be one report generated giving a complete overview. But first I'd like to see how people think about what I did, and how they extend and modify it.
