On Tue, May 21, 2013 at 1:38 PM, Kris Borchers <kris@redhat.com> wrote:
I would be ok with 2 or 3. I can see the advantages and disadvantages of both scenarios. I would never, ever do 1.


 
To me, the src directory is for just that, source, and should never be cluttered with tests.

in maven, it's default that SOURCE code goes to "src/main/$LANGUAGE"; tests (unit tests) go to "src/test/$LANGUAGE"

-M

 

On May 21, 2013, at 4:11 AM, Matthias Wessendorf <matzew@apache.org> wrote:




On Tue, May 21, 2013 at 9:15 AM, Karel Piwko <kpiwko@redhat.com> wrote:
Well, we have 3 options where to put tests:

1/ Have them tightly integrated - that would be src/test
2/ Have them next to actual code - that's current proposal
3/ Have them in separate repository - that's Matthias option

I chose 2/ because that way people are not required to setup anything to

well, it's not really tied to the maven default layout;
folks have to explictily cd into the "tests" folder, at root level;
Also, I guess you need separated CI hooks for that


 
code on the component while being aware something like integration tests
exists and it's not that difficult to fix them if broken by your last commit.

fair point, but they can be always executed against the latest snapshot.

 
That's the main reason why I do not like 3/, separate lifecycle for tests adds
entry barrier for test development and maintenance.

cd tests (at root level), make this already very similar to a separate project, hence it has 
an individual "lifecycle", right ? 

 
Option 1/ is the best if
the set of test tools is stable, which is unfortunately not the case yet,
unfortunately.

For me, personally src/test is more for unit/mock testing. But that's just personal preference.


 

Personally, I do not like integration tests being kept separately. With
Arquillian, the boundary between integration and unit test is very blur, so
so the only point keeping tests separated is developer turnaround - test
execution feedback should be quick. So, if you guys figure out that integration
tests take too much time in future, I'd opt for making smoke profile with a
subset of selected tests and full profile for CI purposes.

Karel

On Mon, 20 May 2013 16:30:24 -0300
Bruno Oliveira <bruno@abstractj.org> wrote:

> Hi Karel, why do not follow conventions? src/test?
>
> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
>
> Karel Piwko wrote:
> > Hi All,
> >
> > I've just sent a PR for PushEE testing [1]. The idea is to write tests
> > covering specification and simply execute those against a real running
> > server instance. More details at [2].
> >
> > I have evaluated multiple API approaches, described here[3], Groovy and
> > Spock seems to be the best to me.
> >
> > Any comments/suggestions/objections very welcomed. My plan is to start
> > covering specs we have so far and run it on a CI server.
> >
> > Thanks,
> >
> > Karel
> >
> > [1] https://github.com/matzew/pushee/pull/6/
> > [2] https://github.com/kpiwko/pushee/blob/tests/tests/readme.txt
> > [3] https://gist.github.com/kpiwko/5612949
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf