Re: Keeping your test source code in a separate, but parallel source tree
On Saturday, July 12, 2003, at 08:02 PM, Dave Ford wrote: The advantage I see is that you get to have test code that has package-level access Actually, you get that by placing them in the same directory also. So that's not really an advantage. and because it's in a separate tree, it's easy to build binaries that don't include all the test code... Obviously, this is easily accomplished by tools such as Ant or Maven by simply excluding *Test That assumes that your test code is so simple that everything fits a pattern like that. If so, yes, your are right. But when there's other code that isn't *Test, then it helps to be able to have a separate tree geir So, back to my question. Why is this a best practice? Maybe it's a common practices, possibly a standard practiced, but no one has yet convinced me it's best practice. Dave Ford Smart Soft - The Developer Training Company http://www.smart-soft.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-434-2093(m) [EMAIL PROTECTED] 203-247-1713(m) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Keeping your test source code in a separate, but parallel source tree
> So, back to my question. Why is this a best practice? Maybe > it's a common > practices, possibly a standard practiced, but no one has yet > convinced me > it's best practice. FWIW, I like the separate package hierarchy because it keeps the "regular" code packages less cluttered. I feel like 10 classes in a package is OK... but if there were 20 classes, 10 of which were tests, and they were all intermingled just seems like it would be visually distracting. Yours, Tom Copeland [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keeping your test source code in a separate, but parallel source tree
> The advantage I see is that you get to have test code that has > package-level access Actually, you get that by placing them in the same directory also. So that's not really an advantage. > and because it's in a separate tree, it's easy to > build binaries that don't include all the test code... Obviously, this is easily accomplished by tools such as Ant or Maven by simply excluding *Test So, back to my question. Why is this a best practice? Maybe it's a common practices, possibly a standard practiced, but no one has yet convinced me it's best practice. Dave Ford Smart Soft - The Developer Training Company http://www.smart-soft.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Keeping your test source code in a separate, but parallel source tree
I do exactly as Dave Ford does - I keep my unit test classes in the same packages as the production code under test. I find it good for the same reasons as Dave outlines, and separating them at delivery time using ant in a fileset is very very simple (once you stick to a consistent naming convention). I took this practise from some junit documentation I read. There's probably little point in discussing the merits and demerits of this practice: it's enough perhaps to say that a lot of developers do things in both ways and it would be great of maven could facilitate both approaches. Brendan. -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: 12 July 2003 17:59 To: Maven Users List Subject: Re: Keeping your test source code in a separate, but parallel source tree On Saturday, July 12, 2003, at 12:20 PM, Dave Ford wrote: > The Maven web site lists "Keeping your test source code in a separate, > but > parallel source tree" as best practices. > > Q1: Why is this a best practice? It just seems like an extra thing to > maintain to me, making package name refactoring for troublesome. I've > been > placing my test class next to the tested class. > > smartsoft.util.Date > smartsoft.util.DateTest > > By naming them this way, they appear next to each other in dir > listings. True, although I rarely ever go digging around in the directory to see what's there. Generally tools do a good job, such as Eclipse or Idea. The advantage I see is that you get to have test code that has package-level access and because it's in a separate tree, it's easy to build binaries that don't include all the test code... geir > > Q2: If I want to continue my practice of keeping them together, is > there any > way to get Maven to support that? > > Thanks > > > Dave Ford > Smart Soft - The Developer Training Company > http://www.smart-soft.com > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-434-2093(m) [EMAIL PROTECTED] 203-247-1713(m) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keeping your test source code in a separate, but parallel source tree
On Saturday, July 12, 2003, at 12:20 PM, Dave Ford wrote: The Maven web site lists "Keeping your test source code in a separate, but parallel source tree" as best practices. Q1: Why is this a best practice? It just seems like an extra thing to maintain to me, making package name refactoring for troublesome. I've been placing my test class next to the tested class. smartsoft.util.Date smartsoft.util.DateTest By naming them this way, they appear next to each other in dir listings. True, although I rarely ever go digging around in the directory to see what's there. Generally tools do a good job, such as Eclipse or Idea. The advantage I see is that you get to have test code that has package-level access and because it's in a separate tree, it's easy to build binaries that don't include all the test code... geir Q2: If I want to continue my practice of keeping them together, is there any way to get Maven to support that? Thanks Dave Ford Smart Soft - The Developer Training Company http://www.smart-soft.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-434-2093(m) [EMAIL PROTECTED] 203-247-1713(m) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
