> So I think that functional testing/performance testing should be put
> to separate projects. I think some things can be improved in
> reactor/multiproject to make such things easier to use and maintain
> So e.g. I would put cactus test cases to separate project.
One potential problem I see wi
> On Thu, 30 Oct 2003 11:37:23 -0500, Alain Javier Guarnieri del Gesu <[EMAIL
> PROTECTED]> said:
>> What does a standalone test case buy you over one with a resource?
> More importantly, are those that adhere to this school of thought
> seeking a solution in Maven to make addendence com
> On Thu, 30 Oct 2003 19:40:13 +0100, Michal Maczka <[EMAIL PROTECTED]> said:
> So I think that functional testing/performance testing should be put
> to separate projects. I think some things can be improved in
> reactor/multiproject to make such things easier to use and maintain
> So e.g. I
> On Thu, 30 Oct 2003 09:18:07 -0500, Alain Javier Guarnieri del Gesu <[EMAIL
> PROTECTED]> said:
> Sound argument. Are you suggesting then that a distinction be made
> between unit, integeration, and acceptence tests in the project
> directory structure?
Yes, this is something I've want
>
> black box, functional, acceptance and integration tests are all
> important but
> they are not unit tests.
?
Isn't it blackbox testing (or in other words "interface testing")?:
public interface Calculator
{
int sum(int a, int b)
}
public class CalculatorImpl
{
...
}
public class Ca
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2003-10-30 11:50]:
> Peter Donald <[EMAIL PROTECTED]> wrote on 31/10/2003 01:21:08 AM:
>
> > On Fri, 31 Oct 2003 01:08 am, Michal Maczka wrote:
> > > Are you going to hardcode samples of HTML or Java files in
> > > your Java code?
> >
> > The link that I s
On Fri, 31 Oct 2003 02:22 am, Michal Maczka wrote:
> It's just so nice to be in the situation when second version of the same
> project and it just happen that API is very different and you have to
> put to the garbage all your mock objects :)
Generally you dont write your own mock objects but use
* Vincent Tence <[EMAIL PROTECTED]> [2003-10-30 14:52]:
> > -Original Message-
> > From: Alain Javier Guarnieri del Gesu [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, October 30, 2003 9:18 AM
> > To: 'Maven Users List'
>
> > Of course this only applies to unit tests. Integration tests and
> > acceptance tests are another story.
>
> Sound argument. Are you suggesting then that a distinction be made
> between unit, integeration, and acceptence tests in the project
> directory structure?
I've been following this thr
> -Original Message-
> From: Alain Javier Guarnieri del Gesu [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 30, 2003 9:18 AM
> To: 'Maven Users List'
> Subject: Re: "src/java" or "src/main/java" ?
>
>
> * Vincent Tence <[E
> > Imagine we will have test code written in python or ... groovy
> >
> > it seems to be more natural: to have (subjective opinion)
> > src/test
> > java
> > jython
> > groovy
>
> To test Java I use a framework that is a mixture of xml and java, so
> my test directories cur
* Vincent Tence <[EMAIL PROTECTED]> [2003-10-30 11:26]:
> I second that as well. Good design + proper use of mock objects
> solve almost 100% of the needs for external dependencies on the
> unit tests, whether test files or environment dependencies such as
> the need to have a DB running. Keep in
* Peter Donald <[EMAIL PROTECTED]> [2003-10-30 09:00]:
> On Thu, 30 Oct 2003 10:22 pm, Michal Maczka wrote:
> > There is a lot of examples of such unit tests.
> > E.g. I18N service which reads messages from XML files. To test it you
> > need to provide few XML files
> > and to place them somewher
* Michal Maczka <[EMAIL PROTECTED]> [2003-10-30 09:27]:
> I am also for
>
> src/main/java
> and
> src/test/java
>
> Imagine we will have test code written in python or ... groovy
>
> it seems to be more natural: to have (subjective opinion)
> src/test
> java
> jython
> g
I really can't see the difference between hard coding the test data in the
code and on the file system.
What does a standalone test case buy you over one with a resource?
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Pub Key:http://blogs.codehaus.org/peop
> Yeah it could be even *shooting* in your *own* *foot*.!
> It's just so nice to be in the situation when second version
> of the same
> project and it just happen that API is very different and you have to
> put to the garbage all your mock objects :).
You should have a look at the dynamic mocks.
Maybe these differences are stemming from using tests for design, ala
TDD, which I am practicing while having Maven as my build tool. This
topic seems to be drifting towards more of a discussion regarding TDD.
I do want to use Maven for my development, and I like the way Maven
embraces practices
story.
- Vincent
> -Original Message-
> From: Jeffrey D. Brekke [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 30, 2003 8:29 AM
> To: Maven Users List
> Subject: Re: "src/java" or "src/main/java" ?
>
>
>
> Yes, I agree 100% with this "
[...]
Note that it's also easier to reuse such data in other similar projects.
That would be what some of us call a code smell ;)
;)
Yeah it could be even *shooting* in your *own* *foot*.!
It's just so nice to be in the situation when second version of the same
project and it just happe
On Fri, 31 Oct 2003 01:08 am, Michal Maczka wrote:
> Are you going to hardcode samples of HTML or Java files in your Java code?
The link that I sent before demonstrated just this
http://spice.sourceforge.net/metaclass/xref-test/org/realityforge/metaclass/tools/compiler/ClassDescriptorCompilerTest
Jeffrey D. Brekke wrote:
Yes, I agree 100% with this "school of thought". I want the tests to
be fast and no external dependencies, even files. I treat the need to
fall back on external resources in programmer tests as a potential
code/design smell. Same with extensive/complex fixture setup.
Yes, I agree 100% with this "school of thought". I want the tests to
be fast and no external dependencies, even files. I treat the need to
fall back on external resources in programmer tests as a potential
code/design smell. Same with extensive/complex fixture setup.
> On Thu, 30 Oct 2003
Jason van Zyl wrote:
On Thu, 2003-10-30 at 06:22, Michal Maczka wrote:
Peter Donald wrote:
On Thu, 30 Oct 2003 01:05 pm, Ben Walding wrote:
The rationale is this:
If you have src/java and src/test, then where do you put resources for
testing?
eg: src/resources, src/test-resources
On Thu, 30 Oct 2003 10:22 pm, Michal Maczka wrote:
> There is a lot of examples of such unit tests.
> E.g. I18N service which reads messages from XML files. To test it you
> need to provide few XML files
> and to place them somewhere. Mock object are not really helpful here.
I am not sure I agre
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2003-10-30 02:53]:
> Sorry this should have been something along the lines of...
>
> I think the src/java fits the one project = one artifact principle better
> than src/main/java - besides what else should go beneath src/main/?
How about source code in o
* Jason van Zyl <[EMAIL PROTECTED]> [2003-10-30 08:42]:
> On Thu, 2003-10-30 at 06:22, Michal Maczka wrote:
>> Peter Donald wrote:
>>> On Thu, 30 Oct 2003 01:05 pm, Ben Walding wrote:
>>> One school of thought suggests that no test should NEVER require
>>> resources external to the TestCase. You
On Thu, 2003-10-30 at 06:22, Michal Maczka wrote:
> Peter Donald wrote:
>
> >On Thu, 30 Oct 2003 01:05 pm, Ben Walding wrote:
> >
> >
> >>The rationale is this:
> >>
> >>If you have src/java and src/test, then where do you put resources for
> >>testing?
> >>
> >>eg: src/resources, src/test-resou
Peter Donald wrote:
On Thu, 30 Oct 2003 01:05 pm, Ben Walding wrote:
The rationale is this:
If you have src/java and src/test, then where do you put resources for
testing?
eg: src/resources, src/test-resources
One school of thought suggests that no test should NEVER require resources
ext
On Thu, 30 Oct 2003 01:05 pm, Ben Walding wrote:
> The rationale is this:
>
> If you have src/java and src/test, then where do you put resources for
> testing?
>
> eg: src/resources, src/test-resources
One school of thought suggests that no test should NEVER require resources
external to the Test
Sorry this should have been something along the lines of...
I think the src/java fits the one project = one artifact principle better
than src/main/java - besides what else should go beneath src/main/?
Freely translated from danish
Cheers
Thomas
[EMAIL PROTECTED] wrote on 30-10-2003 07:04:17:
Olá Per
Du kan ændre det i project.xml men det jeg oftest støder på er src/java -
med mindre man bryder med princippet om et projekt = et artifact så er der
kun et træ af java.
Thomas
Per Olesen <[EMAIL PROTECTED]> wrote on 29-10-2003 21:48:04:
> Hi,
>
> I was wondering what the recommend so
On Thu, 30 Oct 2003 01:05 pm, Ben Walding wrote:
> My preference is for src/main/java (but I wrote the wiki page, so I
> can't really count this is a 2nd vote ;))
It also goes against most existing attention. I can only recall a few projects
that go with that pattern while most go with either src
My preference is for src/main/java (but I wrote the wiki page, so I
can't really count this is a 2nd vote ;))
The rationale is this:
If you have src/java and src/test, then where do you put resources for
testing?
eg: src/resources, src/test-resources
where do you put other items that are requ
On Wed, 2003-10-29 at 15:48, Per Olesen wrote:
> Hi,
>
> I was wondering what the recommend source dir structure is. The MavenWiki page
> at http://wiki.codehaus.org/maven/DirectoryLayout says "src/main/java", but
> the genapp-plugin generates "src/java".
There are a few options floating around
Hi,
I was wondering what the recommend source dir structure is. The MavenWiki page
at http://wiki.codehaus.org/maven/DirectoryLayout says "src/main/java", but
the genapp-plugin generates "src/java".
?
Per
--
Per Olesen @ Nordija A/S - www.nordija.com - main#: +45 70 20 25 10
email: [EMAIL PR
35 matches
Mail list logo
