<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 21, 2013 at 1:38 PM, Kris Borchers <span dir="ltr"><<a href="mailto:kris@redhat.com" target="_blank">kris@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">I would be ok with 2 or 3. I can see the advantages and disadvantages of both scenarios. I would never, ever do 1.</div>
</blockquote><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">
To me, the src directory is for just that, source, and should never be cluttered with tests.</div></blockquote><div><br></div><div style>in maven, it's default that SOURCE code goes to "src/main/$LANGUAGE"; tests (unit tests) go to "src/test/$LANGUAGE"</div>
<div style><br></div><div style>-M</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div class="h5"><div><br><div><div>On May 21, 2013, at 4:11 AM, Matthias Wessendorf <<a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a>> wrote:</div><br><blockquote type="cite">
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 21, 2013 at 9:15 AM, Karel Piwko <span dir="ltr"><<a href="mailto:kpiwko@redhat.com" target="_blank">kpiwko@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Well, we have 3 options where to put tests:<br>
<br>
1/ Have them tightly integrated - that would be src/test<br>
2/ Have them next to actual code - that's current proposal<br>
3/ Have them in separate repository - that's Matthias option<br>
<br>
I chose 2/ because that way people are not required to setup anything to<br></blockquote><div><br></div><div>well, it's not really tied to the maven default layout;</div><div>folks have to explictily cd into the "tests" folder, at root level;</div>
<div>Also, I guess you need separated CI hooks for that</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
code on the component while being aware something like integration tests<br>
exists and it's not that difficult to fix them if broken by your last commit.<br></blockquote><div><br></div><div>fair point, but they can be always executed against the latest snapshot.</div><div><br></div><div>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
That's the main reason why I do not like 3/, separate lifecycle for tests adds<br>
entry barrier for test development and maintenance. </blockquote><div><br></div><div>cd tests (at root level), make this already very similar to a separate project, hence it has </div><div>an individual "lifecycle", right ? </div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Option 1/ is the best if<br>
the set of test tools is stable, which is unfortunately not the case yet,<br>
unfortunately.<br></blockquote><div><br></div><div>For me, personally src/test is more for unit/mock testing. But that's just personal preference.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Personally, I do not like integration tests being kept separately. With<br>
Arquillian, the boundary between integration and unit test is very blur, so<br>
so the only point keeping tests separated is developer turnaround - test<br>
execution feedback should be quick. So, if you guys figure out that integration<br>
tests take too much time in future, I'd opt for making smoke profile with a<br>
subset of selected tests and full profile for CI purposes.<br>
<span><font color="#888888"><br>
Karel<br>
</font></span><div><div><br>
On Mon, 20 May 2013 16:30:24 -0300<br>
Bruno Oliveira <<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>> wrote:<br>
<br>
> Hi Karel, why do not follow conventions? src/test?<br>
><br>
> <a href="http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html" target="_blank">http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html</a><br>
><br>
> Karel Piwko wrote:<br>
> > Hi All,<br>
> ><br>
> > I've just sent a PR for PushEE testing [1]. The idea is to write tests<br>
> > covering specification and simply execute those against a real running<br>
> > server instance. More details at [2].<br>
> ><br>
> > I have evaluated multiple API approaches, described here[3], Groovy and<br>
> > Spock seems to be the best to me.<br>
> ><br>
> > Any comments/suggestions/objections very welcomed. My plan is to start<br>
> > covering specs we have so far and run it on a CI server.<br>
> ><br>
> > Thanks,<br>
> ><br>
> > Karel<br>
> ><br>
> > [1] <a href="https://github.com/matzew/pushee/pull/6/" target="_blank">https://github.com/matzew/pushee/pull/6/</a><br>
> > [2] <a href="https://github.com/kpiwko/pushee/blob/tests/tests/readme.txt" target="_blank">https://github.com/kpiwko/pushee/blob/tests/tests/readme.txt</a><br>
> > [3] <a href="https://gist.github.com/kpiwko/5612949" target="_blank">https://gist.github.com/kpiwko/5612949</a><br>
> > _______________________________________________<br>
> > aerogear-dev mailing list<br>
> > <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
> _______________________________________________<br>
> aerogear-dev mailing list<br>
> <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
<br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Matthias Wessendorf <br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</div></div>
_______________________________________________<br>aerogear-dev mailing list<br><a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></blockquote>
</div><br></div></div></div></div><br>_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Matthias Wessendorf <br>
<br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</div></div>