I think you'll end up creating mock objects for everything including transaction, security, simulating ejbLoad calls, simulating jndi access and so on. I don't think that's a good idea due to EJB's complexity. But if you write your EJB in a way that has minimum or no dependency to EJB then that's fine. I mean if you could write a bean consisting of pure business logic and hide anything else in subclasses (one generated for ejb deployment, the other acting as a mock for containerless scenario).
Ara. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:xdoclet-devel- > [EMAIL PROTECTED]] On Behalf Of Vincent Harcq > Sent: Saturday, February 23, 2002 4:22 AM > To: Devel XDoclet > Subject: [Xdoclet-devel] Junit on Entity bean > > Hi, > I just commit sth that permit to specify in build (and not in sources) > the cmp version to use. > > The idea is that I will generate CMP 1.1 classes for samples, then I > will be able to instantiate, say CustomerCMP, sets some fields on it > calls getData() and see if super classes attributes were set, etc... > Next step would be to create a hack ou Util classes that do'nt go to > JNDI but return a fake implementation of Home, this one in turn will > return fake implementations of remote/local interface that operates on > instances of the CMP class directly. > The persistence of data, would be made into a file (Serialization?) or > sth (no not a database : I want this quick, simple, in a word XP!) > The unit test would need to create() data (SetUp) before being able to > "finder" the bean. (tearDown would remove() so delete my tmp files) > ejbLoad, ejbStore,... Would be called when needed (more thinking here) > > That makes a long time I was thinking of unit testing EJBs outside a > container : Application level unit testing > The idea is "I am testing MY beans, I don't care about testing container > responsabilities (transaction,...). The DD ? I know they are good: > they comes from xdoclet ;)" > > For unit testing ejb inside a container other tools exists and are > necessary as well but are complementary, more low level : transaction, > performance, ... > > This will of course also permit to unit test what xdoclet generates > (from samples or enhanced ones...) > > What do you think ? I am a bit tired, I maybe miss a point. > Do you know anywhere I can find something similar to this. > > Going to bed, > Vincent > > > > _______________________________________________ > Xdoclet-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/xdoclet-devel _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
