Minh sent me this... more testing discussion, my bits inline
On Thu, 20 Sep 2001, Minh Kama Yie wrote:
> something to note is the absence of a stateful session bean in the samples.
> the tx properties are different b/w stateless and stateful session beans no?
not afaik, I need to improve my tx knowledge though...
> suggestion would be to have test cases for each vendor.....as good as it is
> to have a very generic tool with a generic set of tests, you can't ignore
> specifics for each vendor, so test the SPEC functionality for each
> vendor.................
yeah, but thats a _lot_ of work, I still hold the dream of one set of code
working across containers... if the samples did a bit more, and contained
all the comments neccessary to show that you can take an ear file and
deploy it anywhere (ie the jar file would have about 10 different
deployment descriptors)... that'd be an excellent advert for XDoclet.
> i just realised that im not posting this to the list.....probly a good thing
> since you can tell me if im talking out of my ass or not.
hehe (o: on the list now buddy
cheers
dim
>
>
> On Thu, 20 Sep 2001 00:07, you wrote:
> > But isn't what you describe basically what the samples application
> > is? Even if it isn't and thats what we do, where do you propose the
> > test clients sit (junit?) and when are they run?
> >
> > cheers
> > dim
> >
> > On Wed, 19 Sep 2001 [EMAIL PROTECTED] wrote:
> > > There seems to be concensus on the need for testing, and various
> > > opinions for how to do it. As an example, I'll describe how the
> > > WebLogicSubTask can be tested. Anybody's comments are welcome:
> > >
> > > -Add the test code here:
> > > xdoclet/core/test/xdoclet/ejb/vendor/weblogic/
> > >
> > > +-build.xml
> > >
> > > | +-ejbdoclet (test target)
> > > | +-wlsdeploy (test target)
> > >
> > > +-src/xdoclet/test/
> > >
> > > +-CarEJB.java
> > > +-WheelEJB.java
> > > +-DriverEJB.java
> > >
> > > In brief: Each xdoclet task impl should have a separate test directory
> > > structure with sample Java sources with @task:tags. Further, there
> > > should be a build script with targets that invoke XDoclet and possibly
> > > tool-specific validation. The test is successful if the component(s)
> > > can be generated, packaged, deployed and accessed without errors.
> > >
> > > As Ara pointed out, it's hard to write test cases that cover all
> > > combinations, so the test writer will have to be "clever" and write
> > > cases (In my case, EJBs) that cover as much as possible. (For example,
> > > I'll try to cover all kinds of CMR relationships in my test EJBs).
> > >
> > > By separating tests this way, people can run the tests if they have the
> > > appropriate environment. -If they don't, well, they can't. -But there
> > > will always be someone who can.
> > >
> > > Cheers, Aslak.
> > >
> > >
> > > _______________________________________________
> > > 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
>
_______________________________________________
Xdoclet-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
