Ok ok,I was too in a hurry, did not get that this Mock Object concept exists already. This will be for later (or never)
For regression testing, I was planning to have an interface/class comparator that would verify class, methods and fields signature one by one to report differences (assert them). Again this sounds like basic idea that maybe exists somewhere else. Any idea ? It is also an easy thing to do, so... Then I can put the "reference" classes/interfaces in cvs, generate stuff, compare generated home/remote interfaces, PK class, ... Then use classic unit testing to test classes behaviour (PK, Session, ...) For entity bean, as in CMP2 generated files are abstract I will use CMP1.1 generated files for unit test stuff like getData(). Does it seems more reasonable ? > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf > Of Ara Abrahamian > Sent: samedi 23 f�vrier 2002 17:16 > To: [EMAIL PROTECTED]; 'Devel XDoclet' > Subject: RE: [Xdoclet-devel] Junit on Entity bean > > > 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 > > _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
