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
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.
That's the main reason why I do not like 3/, separate lifecycle for tests adds
entry barrier for test development and maintenance. Option 1/ is the best if
the set of test tools is stable, which is unfortunately not the case yet,
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.
On Mon, 20 May 2013 16:30:24 -0300
Bruno Oliveira <bruno(a)abstractj.org> wrote:
Hi Karel, why do not follow conventions? src/test?
Karel Piwko wrote:
> Hi All,
> I've just sent a PR for PushEE testing . The idea is to write tests
> covering specification and simply execute those against a real running
> server instance. More details at .
> I have evaluated multiple API approaches, described here, 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.
>  https://github.com/matzew/pushee/pull/6/
>  https://github.com/kpiwko/pushee/blob/tests/tests/readme.txt
>  https://gist.github.com/kpiwko/5612949
> aerogear-dev mailing list
aerogear-dev mailing list