• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

[Digester] End event threw exception Problem for CactusStrutsTestCase

 
Ranch Hand
Posts: 190
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ken Loh
Ranch Hand
Posts: 190
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 190
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Time is the best teacher, but unfortunately, it kills all of its students - Robin Williams. tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic