Why another testing framework?
Even with tools like Cactus, JUnitEE and HttpUnit, testing Java Servlets and JSP pages is hard, particularly if they contain specific business or presentation logic that needs to be tested. Best practices around J2EE development suggest that logic should be encapsulated in JavaBeans or JSP custom tags for better separation of concerns, maintainability, reusability and to facilitate easier testing. Although JUnit can be used to test JavaBeans, testing custom tags by simply invoking their methods doesn’t make sense. Custom tags are components and therefore need to be tested at that level, in the way that they would normally be used from within a JSP page.
…I’m wondering why the popular frameworks haven’t thought of it… May be I can clarify you why such a small amount of other frameworks were concentrating on this issue: From the definition of Unit test (wee Wikipedia for example) “By definition, it only tests the functionality of the units themselves. Therefore, it may not catch integration errors, performance problems or other system-wide issues.” We never tried this kind of things for any our unit tests because we really don’t care about how performant EasyMock Mocks are 🙂 There are however some other types of JUnit tests that we (automated acceptance tests, e.g. HTTPUnit) have and there we would be most probably more interesting to see, but integration costs of such framework may overweight the benifits. For example, do I need to setup a database to integrate performance testing in my continious integration envoronment, how to see results, should the continous integration build failed in case of performance drop? Too many questi
Related Questions
- Can INCA tell me if there is a compulsory national assessment framework or if national testing is compulsory in other countries?
- Que 32: When a new version of the underlying testing tool is released, is the framework engine also upgraded ?
- What is the regulatory framework for drug and alcohol testing in the NSW rail industry?