Stub/Test Driver Framework ???

Discussions

EJB design: Stub/Test Driver Framework ???

  1. Stub/Test Driver Framework ??? (1 messages)

    Looking for a clean implementation within our existing ECs (EJB Entity Components) and PCs (EJB Process Components) to provide a stub facility. I do not want to create a clone of the existing EJBs as this is more development time as well as additional components to deploy. I want the ability to turn the stub functionality on/off via an xml file (which I already have). I was thinking that the constructor within each EJB should do the initial lookup to determine the runtime mode (i.e stubbed or unstubbed). This would be realized by each method in which it would either call the appropriate business object (for creates, updates, and deletes) and stored procedures (for retrieves) or a generic stub framework to return mock data. The stub framework should capture input passed in via the caller and generate an output file showing both the requesting and returned data for verification purposes. I also want this to be as unintrusive as possible. In other words, I would like to abstract this to a sort of utility class so as not to clutter the existing API code on the components. Any thoughts or suggestions would be greatly appreciated. Thanks.
  2. Stub/Test Driver Framework ???[ Go to top ]

    I haven't tried this, but I suppose you could try re-proxying the beans on the server:

    Have the peer stub of each bean implement the remote interface of the bean (or perhaps a parent business interface which the remote extends). Each bean will then delegate method calls to its peer stub if the XML switch is set.

    Since the stubs are not referenced in the deployment descriptor, they should not be deployed as beans. They should be (in effect) nothing more than dependent objects of the beans.