I don't like mixing packages except if we really needed. Could we wait and see if we need that and "Refactoring/Move To" if needed then ? I want to put the pressure on "black box/regression/comparison test" to have a smooth xjavadoc migration. And I think it is too early to do Unit testing xdoclet classes because of changes that will occurs with xjavadoc migration. I see it for quick test/fix but not more for the moment. Vincent
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf > Of Andrew Stevens > Sent: lundi 11 mars 2002 23:25 > To: [EMAIL PROTECTED] > Subject: Re: XDOCLET UNIT TEST was : RE: [Xdoclet-devel] Re: > [Xdoclet-user] 1.1.2 breakage > > > A wise old hermit known only as Vincent Harcq > <[EMAIL PROTECTED]> once said: > > > I just commit this. > > > > Rules > > ======== > > > > All Test Java sources will be under "xdoclet.test" and > > "xdoclet.retest" (re is for Regression) > > > > In directory "core/test" : > > > > - src/xdoclet/test : put here unit tests for xdoclet > classes. Follow > > same package naming Example > > xdoclet.test.xdoclet.XDocletTagSupportTest > > for unit testing > > xdoclet.XDocletTagSupport > > I thought best practise for junit was to use the same package > structure > under a separate source root, so that the unit tests can access any > fields/members that use the default (package) scope? Putting > everything > below xdoclet.test & xdoclet.retest like this, you lose that ability > (although I'm not sure we have anything in there currently > using package > scope anyway). > > > Andrew. > > _______________________________________________ > 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
