> -----Original Message-----
> From: J. B. Rainsberger [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 21, 2004 9:27 AM
> To: Cactus Users List
> Subject: Re: how to test Session Facade without database
>
>
> Mark Lybarger wrote:
>
> > I'd like to be able to test my Stateless Session EJB's w/o
> relying on data in the database. (initially... later, i'd
> like to remove dependancy on a remote tuxedo call we also
> do). What's the best way to do this? Mock the database?
> Hypersonic database for testing?
>
> My usual approach is to mock the database by a three step approach:
>
> 1. Centralize data access as much as possible
> 2. Extract Interface
> 3. Mock the new interface with EasyMock/jMock
This seems easy enough. I'll take a look at these.
>
> > Our DAO layer is similar to the torque peer setup. We have
> EJBs that call other EJB's or that call static methods on
> Peer classes. The Peer classes return DTOs filled with data
> from the db. All database access is done through these Peer
> classes. I've read in some XP book someplace how to test
> database methods by mocking the database objects, (record set
> mocks, connection mocks), but I'm just not sure how that
> would work out if we're not directly testing the Peer
> classes, but testing the EJB interface itself. We're
> implementing the session facade pattern now (moving code from
> turbine actions) to make functionality more available to
> other processes. And IMO, having testing on this
> functionality is essential. Any insights would be most appreciated.
>
> Get rid of the class-level (static) methods immediately, and
> if you can,
> quickly. They provide no value unless you consider excessive coupling
> valuable. :)
What would you suggest? This is getting a little off from cactus (another forum
suggestion?), but I'd really like to test my ejbs since these components are now
starting to contain functionality that's reusable by other systems.
I notice in the "Junit In Action" book, the bean implementation is being tested
directly. My issue is that my beans are dependant on remote resources obtained during
the create method. Say I have the following:
OrderBean {
ejbCreate () { // get remote reference to cust bean, get ds name from IC}
postOrder ( Order order ) throws CustomerNotFoundException {
customer.verifyCustomer ( order.getCustomerId() );
OrderPeer.insertOrder( order );
}
}
CustomerBean {
ejbCreate () { //get ds name from IC }
verifyCustomer( custId ){
// get db connection from ds.
Connection conn = DbConnectionTool.getConnection ( datasourceName );
CustomerPeer.verifyCustomer( custId, conn );
}
}
CustomerPeer {
public static verifyCustomer ( custId, conn) throws CustomerNotFoundException {
PreparedStatement prepStmt = conn.prepareStatement("select customerId from
customer where cust id = ?");
prepStmt.setInt(1,custId);
prepStmt.execute();
resultSet = prepStmt.executeQuery();
// here is code that says "if cust not found, throw custnotfound exception.
}
}
I'm comfortable with mocking up classes that aren't being tested, but I don't really
like the idea of doing things to my code that forces me to create a Testable version
of my EJB that extends the actual EJB.
sometimes its just nice to let the qa guys handle testing ;).
> --
> 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]
