Hi, A few options:
1/ Create Cactus integration unit test for the create*() methods? I assume they're all calling the database and that's what you wish to test, right? 2/ Another possibility is to have mock objects unit tests (i.e by mocking the database access level) and then a Cactus integration test that tests he conclude() method (and thus the other methods) in integration with the database. 3/ Same as 2 except you don't use Cactus at all and you test functionally (i.e. from the outside) your application (using whatever interfaces it offers to the outside world) -Vincent > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: lundi 28 juin 2004 18:25 > To: [EMAIL PROTECTED] > Subject: EJB Test Design help? > > I need to see if someone an help me to design my Cactus tests for my > EJB's. > I have a composite DTO that has Entities that match: > > CreditAppDto > |--> BusinessCard1 > |--> Bank Account 1 > |--> Bank Account 2 > |-->BusinessLine > |--> Guarantor[1..*] > > Now, this DTo get saved all at once in my Use Case. > > I have spit up the CreditApplicationManager methods into smaller chunks: > > CreditApplicationManager.createCreditApplicaton(...) > CreditApplicationManager.createBusinessCard(...) > CreditApplicationManager.createBusinessLine(...) > CreditApplicationManager.createGuarantor(...) > > But, they all still get called from: > CreditApplicationManager.conclude(CreditApplicationDto) > > Any design thoughts on how to test this scenario? > > > --- > > Thanks... > > Mick Knutson > > > > 525 Market Street, SF, CA 94103 > > (415) 222-1020 > > [EMAIL PROTECTED] > > MAC A0103-223 > --- > > > > --------------------------------------------------------------------- > 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]
