aspose file tools*
The moose likes Testing and the fly likes [Digester] End event threw exception Problem for CactusStrutsTestCase Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Engineering » Testing
Bookmark "[Digester] End event threw exception Problem for CactusStrutsTestCase" Watch "[Digester] End event threw exception Problem for CactusStrutsTestCase" New topic
Author

[Digester] End event threw exception Problem for CactusStrutsTestCase

Ken Loh
Ranch Hand

Joined: Feb 16, 2005
Posts: 190
I got to restart my JBoss 3.2.4 at my Eclipse between two running of tests. Otherwise I would get "[Digester] End event threw exception". This costs me enormous amount of time as I need to restart the server for each correction.

Testing is suppose to be part of agile programming. However, for my case, the enormous time taken due to the need to restarting JBoss is counter-acting the whole purpose of testing.

Is there a way not needing to restart JBoss after each test run ?

Any info would be very much appreciated.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Ken Loh:
Testing is suppose to be part of agile programming. However, for my case, the enormous time taken due to the need to restarting JBoss is counter-acting the whole purpose of testing.

Is there a way not needing to restart JBoss after each test run ?

Note that you're not actually doing unit testing but *integration* testing since you're running your code inside the application server. This kind of tests will inevitably be slower to execute than unit tests.

"Agile programming", as you call it, does not mean that you should run your integration tests every 5 minutes. Most practitioners of Extreme Programming, for example, run their unit tests every couple of minutes but I haven't heard of anyone actually running their integration tests every couple of minutes.

I'd suggest you to separate your integration tests and unit tests so that you can run the unit tests within your IDE (should take less than a minute, preferably less than 10 seconds to run all your unit tests), and you can run the slow integration tests on JBoss from the command prompt, for example, with a script that restarts JBoss, deploys the application, and runs the tests.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Ken Loh
Ranch Hand

Joined: Feb 16, 2005
Posts: 190
First and foremost, thank you for your response. I must apologize for the misleading info in my original post. Please find my clarifications inline...

Originally posted by Lasse Koskela:

Note that you're not actually doing unit testing but *integration* testing since you're running your code inside the application server. This kind of tests will inevitably be slower to execute than unit tests.


You're absolutely true. I should have said integration test rather than unit. As I was using Cactus with Struts (CactusStrutsTest), I was running the test from my servlet container.


"Agile programming", as you call it, does not mean that you should run your integration tests every 5 minutes. Most practitioners of Extreme Programming, for example, run their unit tests every couple of minutes but I haven't heard of anyone actually running their integration tests every couple of minutes.

Again, you're spot-on too in this aspect.

However, what I really meant to say was that when there is a failure, it could take me several times of modifying the codes and re-running the test before I could remove the failure. If I had multiple failures, that would compound the length of time needed. Certainly, needing to restart the app server for each re-run isn't helping.

Now, imagine if I took on a project that has no test-case classes at all and with codes which passing is actually the exception rather than the rule.....

On why using IT instead of UT, please read on...


I'd suggest you to separate your integration tests and unit tests so that you can run the unit tests within your IDE (should take less than a minute, preferably less than 10 seconds to run all your unit tests), and you can run the slow integration tests on JBoss from the command prompt, for example, with a script that restarts JBoss, deploys the application, and runs the tests.


When EJB testing is concerned, I've always been using Cactus. I must admit that it is actually a form of integration testing. You're bringing in a very good point, a point which I originally aiming for to achieve, i.e. unit-testing EJB. However, as time was pressing, I resorted to Cactus to test my EJBs as that was the only option I could find within "browser" reach.

Would you be able to fill me in on alternatives for unit-testing EJBs ?However, let's not sway too far away from my main concern which is to find a solution so that I need not restart my JBoss for each testing no matter if it is unit, integration, functional or any other form.
[ April 17, 2005: Message edited by: Ken Loh ]
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
I'm afraid I can't say much about how to work around the Digester problem. Is the error thrown from your code or from JBoss code? Could you perhaps disable or by-pass whatever is using Digester while running your tests?

Anyway, regarding unit testing EJB's, there's a bunch of things you might want to try, including
- "deploy" your beans on MockEJB, which is a lightweight EJB container plus JNDI implementation (you can deploy the EJB you want to test on MockEJB and put fake implementations of other EJB's your EJB-under-test looks up from JNDI)
- Dumb down your EJB's so that they're just delegating all method calls to a POJO, test the POJO for the business logic, and test the EJB bean class (by just saying "new MyBean()") that it delegates all method calls that it should
Ken Loh
Ranch Hand

Joined: Feb 16, 2005
Posts: 190
The Digester could have been used by Cactus. I worried that the problem will stick on to me so long I use Cactus for testing. Do let me know if you heard of any solution to the #$%^ Digester problem.

One point that I like to add. The Digester problem during cactus test runs only occurs when I do not restart my JBoss after a code modification.

Thanks for the hint on MockEJB. Will dabble on that after this iteration phase.


Originally posted by Lasse Koskela:
I'm afraid I can't say much about how to work around the Digester problem. Is the error thrown from your code or from JBoss code? Could you perhaps disable or by-pass whatever is using Digester while running your tests?

Anyway, regarding unit testing EJB's, there's a bunch of things you might want to try, including
- "deploy" your beans on MockEJB, which is a lightweight EJB container plus JNDI implementation (you can deploy the EJB you want to test on MockEJB and put fake implementations of other EJB's your EJB-under-test looks up from JNDI)
- Dumb down your EJB's so that they're just delegating all method calls to a POJO, test the POJO for the business logic, and test the EJB bean class (by just saying "new MyBean()") that it delegates all method calls that it should

[ April 17, 2005: Message edited by: Ken Loh ]
 
 
subject: [Digester] End event threw exception Problem for CactusStrutsTestCase