RE: Query on current approach to integration tests

2004-04-26 Thread Maczka Michal


 -Original Message-
 From: Tim Stephenson [mailto:[EMAIL PROTECTED]
 Sent: Monday, April 26, 2004 1:29 PM
 To: '[EMAIL PROTECTED]'
 Subject: Query on current approach to integration tests
 
 
 Hi, 
 
 I notice that there have been a few changes to the project xsd (and
 supporting implementation classes) around integration tests 
 sometime over
 the last year when I have been away from maven for one reason 
 or another. 
 
 I have an old problem around how to split out certain tests 
 (which I dub
 'integration tests') from the regular unit tests. There are 2 ways I
 identify these tests: 
 
 a) slow running tests 
 b) tests that require the project code to be deployed 
 before testing
 begins (eg EJBs) 
 
 I used to employ a modified version of the test plugin that 
 offered goals
 like iutest:test and iutest:single, but unfortunately 
 developed this when
 the test plugin was rapidly evolving so it quickly became 
 obsolete. Can
 anyone suggest the preferred approach to solving this problem 
 now that the
 pom support for the integration source directory is deprecated (and
 partially removed) 
 
 Thanks, Tim 
 
The simplest solution is to create one more project for your iu tests.
It can either use jar artifact of main project which you want to test or
directly operate on sources of the main project.
Then you are able to use all goals of test plugin.



Michal

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Query on current approach to integration tests

2004-04-26 Thread Jeffrey D. Brekke

For very simplistic needs, commons-net, we just named our java test
cases with the suffix, 'FunctionalTest'.  Using excludes and some
minimal jelly around the test:match goal, we have a test:functional
goal:

  goal name=test:functional
j:set var=testmatch value=*FunctionalTest/
attainGoal name=test:match/
  /goal

It worked for this case.  I have a larger use-case where I work.
About half the 1800 tests are too slow and depend on external systems.
I've not really come up with a way to do this yet, except maybe
keeping an exclude list, then write custom goals for the integration
tests ( basically how we are doing it in ant now ).

I like the idea of having a separate project, especially for
acceptance/functional testing.  The other thing that the pain of
separating what you define ( and myself btw ) as integration tests in
maven provides is motivation for not writing slow tests or tests that
depend on external dependencies at that level.

 On Mon, 26 Apr 2004 12:28:37 +0100, Tim Stephenson [EMAIL PROTECTED] said:

 Hi, I notice that there have been a few changes to the project xsd
 (and supporting implementation classes) around integration tests
 sometime over the last year when I have been away from maven for one
 reason or another.

 I have an old problem around how to split out certain tests (which I
 dub 'integration tests') from the regular unit tests. There are 2
 ways I identify these tests:

 a) slow running tests b) tests that require the project code to
 be deployed before testing begins (eg EJBs)

 I used to employ a modified version of the test plugin that offered
 goals like iutest:test and iutest:single, but unfortunately
 developed this when the test plugin was rapidly evolving so it
 quickly became obsolete. Can anyone suggest the preferred approach
 to solving this problem now that the pom support for the integration
 source directory is deprecated (and partially removed)

 Thanks, Tim

 The information in this e-mail is intended only for the person or
 entity to which it is addressed and may contain confidential and/or
 privileged material.  If you are not the intended recipient, please
 inform the sender immediately and destroy the e-mail and any
 attachments.  No liability or responsibility whatsoever is accepted
 for any review, retransmission, dissemination or other use or any
 action taken or omitted, in reliance on this e-mail or its contents

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED] For
 additional commands, e-mail: [EMAIL PROTECTED]

-- 
=
Jeffrey D. Brekke   [EMAIL PROTECTED]
Wisconsin,  USA [EMAIL PROTECTED]
[EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]