EJB design: Issues that need to be addressed in J2EE sw quality/testing
I'm currently looking for a problem in the J2EE software world that needs to be addressed from the quality/testing perspective. This would be my master's thesis topic, which means that I would contribute six to eight months of my time to this topic after which I would publish the result to the problem in addition to the tools developed along the way. The types of problems that I'm looking for are ones that are non-trivial and so far have not been (fully) addressed (example: full testing automation of EJB components). Im a software engineering with a lot of experience in OO/Java and issues in software quality, unfortunately I have very little experience with web app software thus I need suggestions for a good thesis topic. In return for a good problem I would post the full results of my research to this site upon completion.
- Posted by: W Dzidek
- Posted on: April 22 2003 10:52 EDT
wdzidek at sce dot carleton dot ca.AAA (the last four characters are not part of my e-mail address, just an anti-spam tactic)
EJB unit testing is one area my employer has already addressed - we just haven't explicitly marketed our product as being for EJB unit testing. We were getting driven insane(er?) by the amount of effort it took just to run and test EJB and web apps, so we created a development environment called Glider that includes an EJB simulator (so it's super fast to run/test code - very little configuration, easy debugging, etc). However, you can also run the EJB container simulator using any IDE or even in an Ant script - it's just a matter of making sure the appropriate JAR is in the classpath. We do this all the time for regression testing of Glider's EJB container simulator. You can find out more about Glider here: http://www.ensemble-systems.com/glideroverview.html.
First off, J2EE != Web. J2EE can be used to make any type of application, and doesn't require the use of JSP/Servlets.
That said, here's some suggestions:
1) If writing persistence code, the test case code ends up being very similar (or identical) to the code being tested, due to the complexity of setting up test cases, especially when object graphs are being used (i.e. when I fetch a Customer, it will read from the Address table and return a composite Customer object wiht referenced Address object). What happens is that these tests are so cumbersome to write that they either don't get written or aren't kept up to date.
2) When writing tests for business logic, the setup is often very complicated, because to test every path through code, sometimes some very contrived cases must be set up for this. Again, this often doesn't get done, or doesn't get updated.
3) Runtime deployment testing. For example, if you have a Message-Driven Bean that receives messages and calls other EJBs, there are two errors that could occur: a) you did not set up a queue/hook your MDB up to the queue. Messages get sent but never picked up. No error is every logged. System just doesn't work. b) Your MDB wasn't deployed properly and can't load some classes it needs. Again, this won't stop app-server startup, and depending on app-server won't even put errors in the log! Again, you'd never know until you noticed the system just isn't working.