6:21 p.m.
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
8:48 p.m.
Hi,
thanks for putting some test work together.
Looking at https://gist.github.com/kpiwko/5612949, this reminds me of what
I have called "integration tests" in previous projects. This is great and
indeed needed!
--> that way you can _really_ tell if something is broken, since executed
against a real (separated) server, and not against something that is mocked.
However, not sure I really like having a new "tests" folder at "root"
level
of the project;
Instead, I'd prefer a separate PushEE-integration-tests project, which does
the same.
For me, tests inside of the project should be more mock/unit/BDD kinda
tests. Integration tests should be on their own repo, IMO
Once, we have an "official" AG-PushEE repo, do you think having these
"integration" in an isolated repo makes sense?
-Matthias
On Mon, May 20, 2013 at 6:21 PM, Karel Piwko <kpiwko(a)redhat.com> 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(a)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
9:30 p.m.
Hi Karel, why do not follow conventions? src/test?
http://maven.apache.org/guides/introduction/introduction-to-the-standard-...
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
9:15 a.m.
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,
unfortunately.
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(a)abstractj.org> wrote:
Hi Karel, why do not follow conventions? src/test?
http://maven.apache.org/guides/introduction/introduction-to-the-standard-...
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
11:11 a.m.
On Tue, May 21, 2013 at 9:15 AM, Karel Piwko <kpiwko(a)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(a)abstractj.org> wrote:
> Hi Karel, why do not follow conventions? src/test?
>
>
http://maven.apache.org/guides/introduction/introduction-to-the-standard-...
>
> 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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)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
1:38 p.m.
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.
On May 21, 2013, at 4:11 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Tue, May 21, 2013 at 9:15 AM, Karel Piwko <kpiwko(a)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(a)abstractj.org> wrote:
> Hi Karel, why do not follow conventions? src/test?
>
>
http://maven.apache.org/guides/introduction/introduction-to-the-standard-...
>
> 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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
1:50 p.m.
On Tue, May 21, 2013 at 1:38 PM, Kris Borchers <kris(a)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(a)apache.org>
wrote:
On Tue, May 21, 2013 at 9:15 AM, Karel Piwko <kpiwko(a)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(a)abstractj.org> wrote:
>
> > Hi Karel, why do not follow conventions? src/test?
> >
> >
>
http://maven.apache.org/guides/introduction/introduction-to-the-standard-...
> >
> > 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(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)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
5:19 p.m.
On Tue, May 21, 2013 at 01:50:19PM +0200, Matthias Wessendorf wrote:
On Tue, May 21, 2013 at 1:38 PM, Kris Borchers
<kris(a)redhat.com> wrote:
> To me, the src directory is for just that, source, and should never be
> cluttered with tests.
At least in Java lands, the tests are written using
source code :P
in maven, it's default that SOURCE code goes to
"src/main/$LANGUAGE"; tests
(unit tests) go to "src/test/$LANGUAGE"
Have y'all considered using
maven-failsafe-plugin[1]? In this case, the
integration tests only run when you invoke mvn verify (and a name
pattern can be specified for the integration tests)
[1]:http://maven.apache.org/surefire/maven-failsafe-plugin/index.html
--
qmx
5:30 p.m.
On Tue, May 21, 2013 at 5:19 PM, Douglas Campos <qmx(a)qmx.me> wrote:
On Tue, May 21, 2013 at 01:50:19PM +0200, Matthias Wessendorf wrote:
> On Tue, May 21, 2013 at 1:38 PM, Kris Borchers <kris(a)redhat.com> wrote:
> > To me, the src directory is for just that, source, and should never be
> > cluttered with tests.
At least in Java lands, the tests are written using source code :P
> in maven, it's default that SOURCE code goes to "src/main/$LANGUAGE";
tests
> (unit tests) go to "src/test/$LANGUAGE"
Have y'all considered using maven-failsafe-plugin[1]? In this case, the
integration tests only run when you invoke mvn verify (and a name
pattern can be specified for the integration tests)
[1]:http://maven.apache.org/surefire/maven-failsafe-plugin/index.html
Used before - not sure, but I do not like mixing unit and integration
tests, in one maven project :)
--
qmx
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)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
5:35 p.m.
BUT ! :)
instead of discussing this to death, however, using
http://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-m...
and putting the integration tests into something like "src/itests" is
OK
for me.
Much better than putting them into "src/test" or "tests" (at root
level)
-M
On Tue, May 21, 2013 at 5:30 PM, Matthias Wessendorf <matzew(a)apache.org>wrote:
On Tue, May 21, 2013 at 5:19 PM, Douglas Campos <qmx(a)qmx.me> wrote:
> On Tue, May 21, 2013 at 01:50:19PM +0200, Matthias Wessendorf wrote:
> > On Tue, May 21, 2013 at 1:38 PM, Kris Borchers <kris(a)redhat.com> wrote:
> > > To me, the src directory is for just that, source, and should never be
> > > cluttered with tests.
> At least in Java lands, the tests are written using source code :P
>
> > in maven, it's default that SOURCE code goes to
"src/main/$LANGUAGE";
> tests
> > (unit tests) go to "src/test/$LANGUAGE"
> Have y'all considered using maven-failsafe-plugin[1]? In this case, the
> integration tests only run when you invoke mvn verify (and a name
> pattern can be specified for the integration tests)
>
> [1]:http://maven.apache.org/surefire/maven-failsafe-plugin/index.html
Used before - not sure, but I do not like mixing unit and integration
tests, in one maven project :)
>
>
> --
> qmx
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)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
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
6:02 p.m.
On Tue, May 21, 2013 at 05:35:38PM +0200, Matthias Wessendorf wrote:
BUT ! :)
instead of discussing this to death, however, using
http://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-m...
and putting the integration tests into something like "src/itests" is
OK
for me.
That's what I'm talking about ;)
Much better than putting them into "src/test" or
"tests" (at root level)
+1
--
qmx
6:05 p.m.
\o/
On Tue, May 21, 2013 at 6:02 PM, Douglas Campos <qmx(a)qmx.me> wrote:
On Tue, May 21, 2013 at 05:35:38PM +0200, Matthias Wessendorf wrote:
> BUT ! :)
>
> instead of discussing this to death, however, using
>
http://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-m...
> and putting the integration tests into something like "src/itests" is
> OK
> for me.
That's what I'm talking about ;)
> Much better than putting them into "src/test" or "tests" (at
root level)
+1
--
qmx
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)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
12:38 p.m.
Ok, we reached a conclusion.
I've put it into separate repo with failsafe plugin, ready to be moved to
pushee src/it once testing tools are stable.
Now, how do I get https://github.com/kpiwko/pushee-integration-tests to
Aerogear org and get r+w access there? I expect that this should
happen the very same day as Matthias' pushee goes to Aerogear org, but I don't
know what you guys need from me.
Karel
On Tue, 21 May 2013 18:05:40 +0200
Matthias Wessendorf <matzew(a)apache.org> wrote:
\o/
On Tue, May 21, 2013 at 6:02 PM, Douglas Campos <qmx(a)qmx.me> wrote:
> On Tue, May 21, 2013 at 05:35:38PM +0200, Matthias Wessendorf wrote:
> > BUT ! :)
> >
> > instead of discussing this to death, however, using
> >
>
http://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-m...
> > and putting the integration tests into something like "src/itests"
is
> > OK
> > for me.
> That's what I'm talking about ;)
>
> > Much better than putting them into "src/test" or "tests"
(at root level)
> +1
>
> --
> qmx
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
3:52 p.m.
I can't see any problems on it, if the integration tests are optional to
run.
mvn test - Only unit tests
mvn myubercommand - integration tests (+1 for add it on CI)
Matthias Wessendorf wrote:
On Tue, May 21, 2013 at 5:19 PM, Douglas Campos <qmx(a)qmx.me
<mailto:qmx@qmx.me>> wrote:
On Tue, May 21, 2013 at 01:50:19PM +0200, Matthias Wessendorf wrote:
> On Tue, May 21, 2013 at 1:38 PM, Kris Borchers <kris(a)redhat.com
<mailto:kris@redhat.com>> wrote:
> > To me, the src directory is for just that, source, and should
never be
> > cluttered with tests.
At least in Java lands, the tests are written using source code :P
> in maven, it's default that SOURCE code goes to
"src/main/$LANGUAGE"; tests
> (unit tests) go to "src/test/$LANGUAGE"
Have y'all considered using maven-failsafe-plugin[1]? In this case, the
integration tests only run when you invoke mvn verify (and a name
pattern can be specified for the integration tests)
[1]:http://maven.apache.org/surefire/maven-failsafe-plugin/index.html
Used before - not sure, but I do not like mixing unit and integration
tests, in one maven project :)
--
qmx
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org <mailto: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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
1:42 p.m.
Seems to me that we might agree on moving tests into separate repository for
now while making them a part of src/test of the project itself once we
stabilize testing tools.
Comments inline.
Karel
On Tue, 21 May 2013 11:11:42 +0200
Matthias Wessendorf <matzew(a)apache.org> wrote:
On Tue, May 21, 2013 at 9:15 AM, Karel Piwko
<kpiwko(a)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
Yes, we need to add one more Maven execution set up in CI.
> 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.
Yes, they will be no matter where the tests are put into. But "cd tests &
fix"
is much less effort compared to check CI job where tests actually are, clone,
fix and rerun.
> 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 ?
It is a separate project. But lifecycle is shared.
> 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.
Right.
>
> 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(a)abstractj.org> wrote:
>
> > Hi Karel, why do not follow conventions? src/test?
> >
> >
>
http://maven.apache.org/guides/introduction/introduction-to-the-standard-...
> >
> > 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(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
1:51 p.m.
On Tue, May 21, 2013 at 1:42 PM, Karel Piwko <kpiwko(a)redhat.com> wrote:
Seems to me that we might agree on moving tests into separate
repository
+1
for
now while making them a part of src/test of the project itself once we
stabilize testing tools.
please no INTEGRATION tests in src/test
-M
Comments inline.
Karel
On Tue, 21 May 2013 11:11:42 +0200
Matthias Wessendorf <matzew(a)apache.org> wrote:
> On Tue, May 21, 2013 at 9:15 AM, Karel Piwko <kpiwko(a)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
>
Yes, we need to add one more Maven execution set up in CI.
>
>
>
> > 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.
Yes, they will be no matter where the tests are put into. But "cd tests &
fix"
is much less effort compared to check CI job where tests actually are,
clone,
fix and rerun.
>
>
>
> > 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 ?
It is a separate project. But lifecycle is shared.
>
>
>
> > 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.
Right.
>
>
>
>
> >
> > 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(a)abstractj.org> wrote:
> >
> > > Hi Karel, why do not follow conventions? src/test?
> > >
> > >
> >
http://maven.apache.org/guides/introduction/introduction-to-the-standard-...
> > >
> > > 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(a)lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
>
>
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)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
5:31 p.m.
On Tue, May 21, 2013 at 09:15:08AM +0200, Karel Piwko wrote:
Well, we have 3 options where to put tests:
1/ Have them tightly integrated - that would be src/test
+1, with failsafe plugin
and a standardized naming pattern
2/ Have them next to actual code - that's current proposal
-1
3/ Have them in separate repository - that's Matthias option
+1, that's the lean route
Personally, I do not like integration tests being kept separately.
With
Arquillian, the boundary between integration and unit test is very blur, so
And
this is what get me pissed off, when I go to run an `mvn test` and
it starts trying to deploy my app to a server.
--
qmx
3:52 p.m.
+1 for #3 (Spock ftw !!)
On Wed, May 22, 2013 at 3:49 PM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
+1 for option 3
Karel Piwko wrote:
> 3/ Have them in separate repository - that's Matthias option
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
11:27 p.m.
Karel,
I had a look at your repo on how to setup spock test with arquillian. I've
run into a mvn dependency issue. I had to replace:
https://github.com/kpiwko/pushee-integration-tests/blob/master/pom.xml#L20
ie:
<version.org.jboss.shrinkwrap.resolver>2.0.0-beta-4-SNAPSHOT
</version.org.jboss.shrinkwrap.resolver>
by
<version.org.jboss.shrinkwrap.resolver>2.0.0-cr-1-SNAPSHOT</version.org.jboss.shrinkwrap.resolver>
BTW +1 for having test into src/it it's always good to keep test close to
src.
Cheers,
Corinne
On 22 May 2013 15:52, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
+1 for #3 (Spock ftw !!)
On Wed, May 22, 2013 at 3:49 PM, Bruno Oliveira <bruno(a)abstractj.org>wrote:
> +1 for option 3
>
> Karel Piwko wrote:
> > 3/ Have them in separate repository - that's Matthias option
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
2:18 p.m.
Thank Corinne,
nice catch! I'll update to 2.0.0-beta-5, as soon as it will hit Maven Central,
it was released today, so this step would not be necessary at all.
Karel
On Mon, 3 Jun 2013 23:27:20 +0200
Corinne Krych <corinnekrych(a)gmail.com> wrote:
Karel,
I had a look at your repo on how to setup spock test with arquillian. I've
run into a mvn dependency issue. I had to replace:
https://github.com/kpiwko/pushee-integration-tests/blob/master/pom.xml#L20
ie:
<version.org.jboss.shrinkwrap.resolver>2.0.0-beta-4-SNAPSHOT
</version.org.jboss.shrinkwrap.resolver>
by
<version.org.jboss.shrinkwrap.resolver>2.0.0-cr-1-SNAPSHOT</version.org.jboss.shrinkwrap.resolver>
BTW +1 for having test into src/it it's always good to keep test close to
src.
Cheers,
Corinne
On 22 May 2013 15:52, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
> +1 for #3 (Spock ftw !!)
>
>
> On Wed, May 22, 2013 at 3:49 PM, Bruno Oliveira <bruno(a)abstractj.org>wrote:
>
>> +1 for option 3
>>
>> Karel Piwko wrote:
>> > 3/ Have them in separate repository - that's Matthias option
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
9:05 a.m.
On Tue, 4 Jun 2013 14:18:33 +0200
Karel Piwko <kpiwko(a)redhat.com> wrote:
Thank Corinne,
nice catch! I'll update to 2.0.0-beta-5, as soon as it will hit Maven Central,
it was released today, so this step would not be necessary at all.
Updated, you don't have to build SWR from sources anymore.
Karel
On Mon, 3 Jun 2013 23:27:20 +0200
Corinne Krych <corinnekrych(a)gmail.com> wrote:
> Karel,
>
> I had a look at your repo on how to setup spock test with arquillian. I've
> run into a mvn dependency issue. I had to replace:
> https://github.com/kpiwko/pushee-integration-tests/blob/master/pom.xml#L20
> ie:
> <version.org.jboss.shrinkwrap.resolver>2.0.0-beta-4-SNAPSHOT
> </version.org.jboss.shrinkwrap.resolver>
> by
>
<version.org.jboss.shrinkwrap.resolver>2.0.0-cr-1-SNAPSHOT</version.org.jboss.shrinkwrap.resolver>
>
>
> BTW +1 for having test into src/it it's always good to keep test close to
> src.
>
> Cheers,
> Corinne
>
>
> On 22 May 2013 15:52, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
>
> > +1 for #3 (Spock ftw !!)
> >
> >
> > On Wed, May 22, 2013 at 3:49 PM, Bruno Oliveira
> > <bruno(a)abstractj.org>wrote:
> >
> >> +1 for option 3
> >>
> >> Karel Piwko wrote:
> >> > 3/ Have them in separate repository - that's Matthias option
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
9:46 a.m.
Coool
Might have to update my gist then...
Here is asmall gist with all doc and ink to do integration testing for
Pushee
https://gist.github.com/corinnekrych/5712058
++
Corinne
On 5 June 2013 09:05, Karel Piwko <kpiwko(a)redhat.com> wrote:
On Tue, 4 Jun 2013 14:18:33 +0200
Karel Piwko <kpiwko(a)redhat.com> wrote:
> Thank Corinne,
>
> nice catch! I'll update to 2.0.0-beta-5, as soon as it will hit Maven
Central,
> it was released today, so this step would not be necessary at all.
>
Updated, you don't have to build SWR from sources anymore.
> Karel
>
> On Mon, 3 Jun 2013 23:27:20 +0200
> Corinne Krych <corinnekrych(a)gmail.com> wrote:
>
> > Karel,
> >
> > I had a look at your repo on how to setup spock test with arquillian.
I've
> > run into a mvn dependency issue. I had to replace:
> >
https://github.com/kpiwko/pushee-integration-tests/blob/master/pom.xml#L20
> > ie:
> > <version.org.jboss.shrinkwrap.resolver>2.0.0-beta-4-SNAPSHOT
> > </version.org.jboss.shrinkwrap.resolver>
> > by
> >
<version.org.jboss.shrinkwrap.resolver>2.0.0-cr-1-SNAPSHOT</version.org.jboss.shrinkwrap.resolver>
> >
> >
> > BTW +1 for having test into src/it it's always good to keep test close
to
> > src.
> >
> > Cheers,
> > Corinne
> >
> >
> > On 22 May 2013 15:52, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
> >
> > > +1 for #3 (Spock ftw !!)
> > >
> > >
> > > On Wed, May 22, 2013 at 3:49 PM, Bruno Oliveira
> > > <bruno(a)abstractj.org>wrote:
> > >
> > >> +1 for option 3
> > >>
> > >> Karel Piwko wrote:
> > >> > 3/ Have them in separate repository - that's Matthias option
> > >> _______________________________________________
> > >> aerogear-dev mailing list
> > >> aerogear-dev(a)lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >>
> > >
> > >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
4:34 a.m.
On Mon, May 20, 2013 at 06:21:34PM +0200, Karel Piwko wrote:
I have evaluated multiple API approaches, described here[3], Groovy
and Spock
seems to be the best to me.
And now I regret badly having missed the word
"Groovy" between the
provided options when I've gone to review the push server codebase.
#sadpanda :(
--
qmx
9:08 a.m.
Don't focus on Groovy (if it makes you sad), emphasis is on Spock!
#HappyPuppy :)
++
Corinne
On Jul 14, 2013, at 4:34 AM, Douglas Campos <qmx(a)qmx.me> wrote:
On Mon, May 20, 2013 at 06:21:34PM +0200, Karel Piwko wrote:
> I have evaluated multiple API approaches, described here[3], Groovy and Spock
> seems to be the best to me.
And now I regret badly having missed the word "Groovy" between the
provided options when I've gone to review the push server codebase.
#sadpanda :(
--
qmx
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
3:22 p.m.
Do we have a good reason to use Spock instead of conventional tools in
Java? Something that only spock can solve?
Our tests can be written in Java? Maybe I missed the point, but have a
project based in personal taste doesn't make sense to me.
I would love to write my tests with rspec and JRuby, which doesn't mean
I will start to do it.
Corinne Krych wrote:
Don't focus on Groovy (if it makes you sad), emphasis is on
Spock!
#HappyPuppy :)
++
Corinne
On Jul 14, 2013, at 4:34 AM, Douglas Campos<qmx(a)qmx.me> wrote:
> On Mon, May 20, 2013 at 06:21:34PM +0200, Karel Piwko wrote:
>> I have evaluated multiple API approaches, described here[3], Groovy and Spock
>> seems to be the best to me.
> And now I regret badly having missed the word "Groovy" between the
> provided options when I've gone to review the push server codebase.
>
> #sadpanda :(
>
> --
> qmx
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
abstractj
3:26 p.m.
On Mon, Jul 15, 2013 at 3:22 PM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
Do we have a good reason to use Spock instead of conventional tools
in
Java? Something that only spock can solve?
Our tests can be written in Java? Maybe I missed the point, but have a
project based in personal taste doesn't make sense to me.
I would love to write my tests with rspec and JRuby, which doesn't mean
I will start to do it.
good point
Corinne Krych wrote:
> Don't focus on Groovy (if it makes you sad), emphasis is on Spock!
>
> #HappyPuppy :)
>
> ++
> Corinne
> On Jul 14, 2013, at 4:34 AM, Douglas Campos<qmx(a)qmx.me> wrote:
>
>> On Mon, May 20, 2013 at 06:21:34PM +0200, Karel Piwko wrote:
>>> I have evaluated multiple API approaches, described here[3], Groovy
and Spock
>>> seems to be the best to me.
>> And now I regret badly having missed the word "Groovy" between the
>> provided options when I've gone to review the push server codebase.
>>
>> #sadpanda :(
>>
>> --
>> qmx
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
abstractj
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)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
3:33 p.m.
On Mon, Jul 15, 2013 at 3:22 PM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
Do we have a good reason to use Spock instead of conventional tools
in
Java? Something that only spock can solve?
Our tests can be written in Java? Maybe I missed the point, but have a
project based in personal taste doesn't make sense to me.
I would love to write my tests with rspec and JRuby, which doesn't mean
I will start to do it.
Like Corinne said, it's beyond the language. It is more about the
readability / auto documentation of the tests ...
Corinne Krych wrote:
> Don't focus on Groovy (if it makes you sad), emphasis is on Spock!
>
> #HappyPuppy :)
>
> ++
> Corinne
> On Jul 14, 2013, at 4:34 AM, Douglas Campos<qmx(a)qmx.me> wrote:
>
>> On Mon, May 20, 2013 at 06:21:34PM +0200, Karel Piwko wrote:
>>> I have evaluated multiple API approaches, described here[3], Groovy
and Spock
>>> seems to be the best to me.
>> And now I regret badly having missed the word "Groovy" between the
>> provided options when I've gone to review the push server codebase.
>>
>> #sadpanda :(
>>
>> --
>> qmx
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
abstractj
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
3:40 p.m.
On Mon, 15 Jul 2013 10:22:37 -0300
Bruno Oliveira <bruno(a)abstractj.org> wrote:
Do we have a good reason to use Spock instead of conventional tools
in
Java? Something that only spock can solve?
Spock gives us BDD syntax, which I think is more readable for tests that are
supposed to cover specifications.
The technical reason to choose Groovy than Java was far superior support to
JSON, with is used to define content of REST requests. Spock also added far
better support for parametrized tests.
What do you mean by conventional tooling? Groovy works in IDE (at
leasts JBDS/Eclipse, IntelliJ), it is compatible with JUnit test runner, you
can debug tests from IDE, and you can also do the same in setup it using Maven.
Also, it runs on Travis without any external configuration required.
Our tests can be written in Java? Maybe I missed the point, but have a
project based in personal taste doesn't make sense to me.
For tests that require managing test environment, such as preparing running
server and running non-mocked tests in isolation, Java is the only language
where appropriate tooling exists imho. Groovy is a syntax sugar to make it
nicer.
I would love to write my tests with rspec and JRuby, which doesn't mean
I will start to do it.
I'm not a Groovy fan, to make it clear. But I'm always trying to select the
tool that fits the purpose the best, and according to the POC sent month ago
Groovy and Spock was simply the best offering.
Corinne Krych wrote:
> Don't focus on Groovy (if it makes you sad), emphasis is on Spock!
>
> #HappyPuppy :)
>
> ++
> Corinne
> On Jul 14, 2013, at 4:34 AM, Douglas Campos<qmx(a)qmx.me> wrote:
>
>> On Mon, May 20, 2013 at 06:21:34PM +0200, Karel Piwko wrote:
>>> I have evaluated multiple API approaches, described here[3], Groovy and
>>> Spock seems to be the best to me.
>> And now I regret badly having missed the word "Groovy" between the
>> provided options when I've gone to review the push server codebase.
>>
>> #sadpanda :(
>>
>> --
>> qmx
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
3:46 p.m.
I'm a Groovy fan.
I'm new to Spock though and I'm impressed by its expressiveness.
It's also fit very fluently wit Java. Easy use of RestAssured libraries.
Corinne
On 15 July 2013 15:40, Karel Piwko <kpiwko(a)redhat.com> wrote:
On Mon, 15 Jul 2013 10:22:37 -0300
Bruno Oliveira <bruno(a)abstractj.org> wrote:
> Do we have a good reason to use Spock instead of conventional tools in
> Java? Something that only spock can solve?
Spock gives us BDD syntax, which I think is more readable for tests that
are
supposed to cover specifications.
The technical reason to choose Groovy than Java was far superior support to
JSON, with is used to define content of REST requests. Spock also added far
better support for parametrized tests.
What do you mean by conventional tooling? Groovy works in IDE (at
leasts JBDS/Eclipse, IntelliJ), it is compatible with JUnit test runner,
you
can debug tests from IDE, and you can also do the same in setup it using
Maven.
Also, it runs on Travis without any external configuration required.
>
> Our tests can be written in Java? Maybe I missed the point, but have a
> project based in personal taste doesn't make sense to me.
For tests that require managing test environment, such as preparing running
server and running non-mocked tests in isolation, Java is the only language
where appropriate tooling exists imho. Groovy is a syntax sugar to make it
nicer.
>
> I would love to write my tests with rspec and JRuby, which doesn't mean
> I will start to do it.
I'm not a Groovy fan, to make it clear. But I'm always trying to select the
tool that fits the purpose the best, and according to the POC sent month
ago
Groovy and Spock was simply the best offering.
>
> Corinne Krych wrote:
> > Don't focus on Groovy (if it makes you sad), emphasis is on Spock!
> >
> > #HappyPuppy :)
> >
> > ++
> > Corinne
> > On Jul 14, 2013, at 4:34 AM, Douglas Campos<qmx(a)qmx.me> wrote:
> >
> >> On Mon, May 20, 2013 at 06:21:34PM +0200, Karel Piwko wrote:
> >>> I have evaluated multiple API approaches, described here[3], Groovy
and
> >>> Spock seems to be the best to me.
> >> And now I regret badly having missed the word "Groovy" between
the
> >> provided options when I've gone to review the push server codebase.
> >>
> >> #sadpanda :(
> >>
> >> --
> >> qmx
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
3:54 p.m.
On Mon, Jul 15, 2013 at 3:46 PM, Corinne Krych <corinnekrych(a)gmail.com>wrote:
I'm a Groovy fan.
I'm new to Spock though and I'm impressed by its expressiveness.
It's also fit very fluently wit Java. Easy use of RestAssured libraries.
I guess the point is: plain java lowers the bar, for new contributors.
Is there a "java spock version" like BDD framework ?
-Matthias
Corinne
On 15 July 2013 15:40, Karel Piwko <kpiwko(a)redhat.com> wrote:
> On Mon, 15 Jul 2013 10:22:37 -0300
> Bruno Oliveira <bruno(a)abstractj.org> wrote:
>
> > Do we have a good reason to use Spock instead of conventional tools in
> > Java? Something that only spock can solve?
>
> Spock gives us BDD syntax, which I think is more readable for tests that
> are
> supposed to cover specifications.
>
> The technical reason to choose Groovy than Java was far superior support
> to
> JSON, with is used to define content of REST requests. Spock also added
> far
> better support for parametrized tests.
>
> What do you mean by conventional tooling? Groovy works in IDE (at
> leasts JBDS/Eclipse, IntelliJ), it is compatible with JUnit test runner,
> you
> can debug tests from IDE, and you can also do the same in setup it using
> Maven.
> Also, it runs on Travis without any external configuration required.
>
> >
> > Our tests can be written in Java? Maybe I missed the point, but have a
> > project based in personal taste doesn't make sense to me.
>
> For tests that require managing test environment, such as preparing
> running
> server and running non-mocked tests in isolation, Java is the only
> language
> where appropriate tooling exists imho. Groovy is a syntax sugar to make it
> nicer.
>
> >
> > I would love to write my tests with rspec and JRuby, which doesn't mean
> > I will start to do it.
>
> I'm not a Groovy fan, to make it clear. But I'm always trying to select
> the
> tool that fits the purpose the best, and according to the POC sent month
> ago
> Groovy and Spock was simply the best offering.
>
> >
> > Corinne Krych wrote:
> > > Don't focus on Groovy (if it makes you sad), emphasis is on Spock!
> > >
> > > #HappyPuppy :)
> > >
> > > ++
> > > Corinne
> > > On Jul 14, 2013, at 4:34 AM, Douglas Campos<qmx(a)qmx.me> wrote:
> > >
> > >> On Mon, May 20, 2013 at 06:21:34PM +0200, Karel Piwko wrote:
> > >>> I have evaluated multiple API approaches, described here[3],
Groovy
> and
> > >>> Spock seems to be the best to me.
> > >> And now I regret badly having missed the word "Groovy"
between the
> > >> provided options when I've gone to review the push server
codebase.
> > >>
> > >> #sadpanda :(
> > >>
> > >> --
> > >> qmx
> > >> _______________________________________________
> > >> aerogear-dev mailing list
> > >> aerogear-dev(a)lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> > >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)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
4:06 p.m.
Good stuff with Groovy, you can use Java syntax which is why it's friendly to new
comers.
Spock DSL is based on Groovy Dynamic nature though. No Java Spock version (not that I
know).
Corinne
On Jul 15, 2013, at 3:54 PM, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Mon, Jul 15, 2013 at 3:46 PM, Corinne Krych <corinnekrych(a)gmail.com> wrote:
I'm a Groovy fan.
I'm new to Spock though and I'm impressed by its expressiveness.
It's also fit very fluently wit Java. Easy use of RestAssured libraries.
I guess the point is: plain java lowers the bar, for new contributors.
Is there a "java spock version" like BDD framework ?
-Matthias
Corinne
On 15 July 2013 15:40, Karel Piwko <kpiwko(a)redhat.com> wrote:
On Mon, 15 Jul 2013 10:22:37 -0300
Bruno Oliveira <bruno(a)abstractj.org> wrote:
> Do we have a good reason to use Spock instead of conventional tools in
> Java? Something that only spock can solve?
Spock gives us BDD syntax, which I think is more readable for tests that are
supposed to cover specifications.
The technical reason to choose Groovy than Java was far superior support to
JSON, with is used to define content of REST requests. Spock also added far
better support for parametrized tests.
What do you mean by conventional tooling? Groovy works in IDE (at
leasts JBDS/Eclipse, IntelliJ), it is compatible with JUnit test runner, you
can debug tests from IDE, and you can also do the same in setup it using Maven.
Also, it runs on Travis without any external configuration required.
>
> Our tests can be written in Java? Maybe I missed the point, but have a
> project based in personal taste doesn't make sense to me.
For tests that require managing test environment, such as preparing running
server and running non-mocked tests in isolation, Java is the only language
where appropriate tooling exists imho. Groovy is a syntax sugar to make it
nicer.
>
> I would love to write my tests with rspec and JRuby, which doesn't mean
> I will start to do it.
I'm not a Groovy fan, to make it clear. But I'm always trying to select the
tool that fits the purpose the best, and according to the POC sent month ago
Groovy and Spock was simply the best offering.
>
> Corinne Krych wrote:
> > Don't focus on Groovy (if it makes you sad), emphasis is on Spock!
> >
> > #HappyPuppy :)
> >
> > ++
> > Corinne
> > On Jul 14, 2013, at 4:34 AM, Douglas Campos<qmx(a)qmx.me> wrote:
> >
> >> On Mon, May 20, 2013 at 06:21:34PM +0200, Karel Piwko wrote:
> >>> I have evaluated multiple API approaches, described here[3], Groovy
and
> >>> Spock seems to be the best to me.
> >> And now I regret badly having missed the word "Groovy" between
the
> >> provided options when I've gone to review the push server codebase.
> >>
> >> #sadpanda :(
> >>
> >> --
> >> qmx
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
4:52 p.m.
On Mon, 15 Jul 2013 15:54:13 +0200
Matthias Wessendorf <matzew(a)apache.org> wrote:
On Mon, Jul 15, 2013 at 3:46 PM, Corinne Krych
<corinnekrych(a)gmail.com>wrote:
> I'm a Groovy fan.
> I'm new to Spock though and I'm impressed by its expressiveness.
> It's also fit very fluently wit Java. Easy use of RestAssured libraries.
>
I guess the point is: plain java lowers the bar, for new contributors.
Is there a "java spock version" like BDD framework ?
There is JBehave: http://jbehave.org/. I've been experimenting with it, but
tons of boilerplate imho compared to Spock.
-Matthias
>
> Corinne
>
>
> On 15 July 2013 15:40, Karel Piwko <kpiwko(a)redhat.com> wrote:
>
>> On Mon, 15 Jul 2013 10:22:37 -0300
>> Bruno Oliveira <bruno(a)abstractj.org> wrote:
>>
>> > Do we have a good reason to use Spock instead of conventional tools in
>> > Java? Something that only spock can solve?
>>
>> Spock gives us BDD syntax, which I think is more readable for tests that
>> are
>> supposed to cover specifications.
>>
>> The technical reason to choose Groovy than Java was far superior support
>> to
>> JSON, with is used to define content of REST requests. Spock also added
>> far
>> better support for parametrized tests.
>>
>> What do you mean by conventional tooling? Groovy works in IDE (at
>> leasts JBDS/Eclipse, IntelliJ), it is compatible with JUnit test runner,
>> you
>> can debug tests from IDE, and you can also do the same in setup it using
>> Maven.
>> Also, it runs on Travis without any external configuration required.
>>
>> >
>> > Our tests can be written in Java? Maybe I missed the point, but have a
>> > project based in personal taste doesn't make sense to me.
>>
>> For tests that require managing test environment, such as preparing
>> running
>> server and running non-mocked tests in isolation, Java is the only
>> language
>> where appropriate tooling exists imho. Groovy is a syntax sugar to make it
>> nicer.
>>
>> >
>> > I would love to write my tests with rspec and JRuby, which doesn't
mean
>> > I will start to do it.
>>
>> I'm not a Groovy fan, to make it clear. But I'm always trying to select
>> the
>> tool that fits the purpose the best, and according to the POC sent month
>> ago
>> Groovy and Spock was simply the best offering.
>>
>> >
>> > Corinne Krych wrote:
>> > > Don't focus on Groovy (if it makes you sad), emphasis is on
Spock!
>> > >
>> > > #HappyPuppy :)
>> > >
>> > > ++
>> > > Corinne
>> > > On Jul 14, 2013, at 4:34 AM, Douglas Campos<qmx(a)qmx.me> wrote:
>> > >
>> > >> On Mon, May 20, 2013 at 06:21:34PM +0200, Karel Piwko wrote:
>> > >>> I have evaluated multiple API approaches, described here[3],
Groovy
>> and
>> > >>> Spock seems to be the best to me.
>> > >> And now I regret badly having missed the word "Groovy"
between the
>> > >> provided options when I've gone to review the push server
codebase.
>> > >>
>> > >> #sadpanda :(
>> > >>
>> > >> --
>> > >> qmx
>> > >> _______________________________________________
>> > >> aerogear-dev mailing list
>> > >> aerogear-dev(a)lists.jboss.org
>> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> > >
>> > >
>> > > _______________________________________________
>> > > aerogear-dev mailing list
>> > > aerogear-dev(a)lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> >
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
3:53 p.m.
Conventional tooling, I mean the common frameworks already existent into
Java environment: JUnit...blah blah blah
If you think is the best and only Spock can solve our testing problem,
it's ok. But to me is hard to maintain 2 languages into a single
project. Java for development, Groovy for testing
If the argument is the BDD syntax, readability. I can achieve the same
with Ruby :)
But if you guys are all comfortable with it, follow your heart if it's
something specific to the push project.
Karel Piwko wrote:
On Mon, 15 Jul 2013 10:22:37 -0300
Bruno Oliveira<bruno(a)abstractj.org> wrote:
> Do we have a good reason to use Spock instead of conventional tools in
> Java? Something that only spock can solve?
Spock gives us BDD syntax, which I think is more readable for tests that are
supposed to cover specifications.
The technical reason to choose Groovy than Java was far superior support to
JSON, with is used to define content of REST requests. Spock also added far
better support for parametrized tests.
What do you mean by conventional tooling? Groovy works in IDE (at
leasts JBDS/Eclipse, IntelliJ), it is compatible with JUnit test runner, you
can debug tests from IDE, and you can also do the same in setup it using Maven.
Also, it runs on Travis without any external configuration required.
> Our tests can be written in Java? Maybe I missed the point, but have a
> project based in personal taste doesn't make sense to me.
For tests that require managing test environment, such as preparing running
server and running non-mocked tests in isolation, Java is the only language
where appropriate tooling exists imho. Groovy is a syntax sugar to make it
nicer.
> I would love to write my tests with rspec and JRuby, which doesn't mean
> I will start to do it.
I'm not a Groovy fan, to make it clear. But I'm always trying to select the
tool that fits the purpose the best, and according to the POC sent month ago
Groovy and Spock was simply the best offering.
> Corinne Krych wrote:
>> Don't focus on Groovy (if it makes you sad), emphasis is on Spock!
>>
>> #HappyPuppy :)
>>
>> ++
>> Corinne
>> On Jul 14, 2013, at 4:34 AM, Douglas Campos<qmx(a)qmx.me> wrote:
>>
>>> On Mon, May 20, 2013 at 06:21:34PM +0200, Karel Piwko wrote:
>>>> I have evaluated multiple API approaches, described here[3], Groovy and
>>>> Spock seems to be the best to me.
>>> And now I regret badly having missed the word "Groovy" between the
>>> provided options when I've gone to review the push server codebase.
>>>
>>> #sadpanda :(
>>>
>>> --
>>> qmx
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
abstractj
3931
days inactive
3987
days old
33 comments
7 participants
participants (7)
-
Bruno Oliveira -
Corinne Krych -
Douglas Campos -
Karel Piwko -
Kris Borchers -
Matthias Wessendorf -
Sebastien Blanc