Jayaram -- Don't lose sight of the fact that you're building a "unit" test. When the component you're testing starts calling and relying upon the behavior of outside resources (the session EJB and "another MDB" in your case), you start to move from the realm of "unit" testing into the realm of "system" or "integration" testing. When you unit test a component, the testing should be done in a manner that is as isolated as possible. Since your unit test for MDB1 relies on the proper behavior of the session ejb and "another MDB", you'll end up creating a test that will fail for reasons not directly related to the component you're testing.
Mock objects will definitely provide you with the isolation that you need in order to test MDB1. Chapter 7 in Vincent's book provides some excellent information on accomplishing this. I use the MockObjects framework (www.mockobjects.com) extensively. In your case, all you would need to do is (a) provide MDB1 with a 'mocked-up' version of the session ejb, (b) tell the mocked up object what method(s) should be called and what, if anything, should be returned by those method invocations, (c) invoke the onMessage method on MDB1 and (d) ask the mocked-up session EJB to verify that all of the methods that should have been called were indeed called. Step (a) is probably the most difficult, but Vincent's book provides some excellent information on how you can accomplish this. BTW, the books that were recommended will definitely help. They were a tremendous benefit to me. Ron Gallagher Atlanta, GA -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 25, 2004 11:41 AM To: Cactus Users List Cc: Cactus Users List Subject: Re: Testing MDB I am not sure I understood the solution completely, let me explain my problem again. May be I should read the books suggested. There are 3 components a) the MDB (lets say MDB1) which I want to test, b) the session ejb, and c) another MDB (lets say MDB2) which the session ejb calls. Now, if I call the extracted method in the MDB1 directly, it will make a further call to session ejb which in turns asynchronously calls MDB2. Both session ejb and MDB2 create records in the database. Now I want to test that the records are being properly created. The testXXX() method will succeed for only the records created in the session ejb and will fail for the tests of records created in MDB2 as the MDB2 may not have been completed. Now I have a situation where MDB1 did not fail but the test cases shows it has failed. Will mock objects or the suggested techniques, help me test the MDB1 completely? Thanks Jayaraman "J. B. Rainsberger" To: Cactus Users List <[EMAIL PROTECTED]> <[EMAIL PROTECTED] cc: om> Subject: Re: Testing MDB 05/24/2004 08:39 PM Please respond to "Cactus Users List" [EMAIL PROTECTED] wrote: > The problem with this approach, which I also found at > http://marc.theaimsgroup.com/?l=cactus-user&m=100879309609213&w=2 and tried > is, the MDB calls a session ejb and this might again call another MDB > (There is a complex workflow design behind that). So it may be > possible to > make a call to the first MDB's onMessage(), but this will return back soon > and the testXXX() methods might fail like the previous scenario. Presumably the MDB retrieves the Session EJB from JNDI. The standard solution to this is this: 1. Move the code that retrieves the Session EJB to the top of the onMessage() method. 2. Apply Extract Method to the rest of onMessage() so that the new method takes the Session EJB remote component interface as a parameter. 3. Test the newly extracted method directly without the container. 4. Verify your deployment descriptor to make sure that you deploy the Session EJB correctly. See JUnit Recipes: Practical Programmer Testing Methods for more. :) -- J. B. Rainsberger, Diaspar Software Services http://www.diasparsoftware.com :: +1 416 791-8603 Let's write software that people understand --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
