Re: [aerogear-dev] To Groovy or not to Groovy in integration tests

On Thu, 18 Jul 2013 18:58:01 +0200 Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > On Thu, Jul 18, 2013 at 4:16 PM, Karel Piwko <kpiwko(a)redhat.com&gt; wrote: > >> On Tue, 16 Jul 2013 12:18:40 -0300 >> Douglas Campos <qmx(a)qmx.me&gt; wrote: >> >>> Thanks Karel for the well balanced email. >>> >>> This discussion will never reach an agreement, because it's a biased >>> discussion, and we do have personal preferences involved - I for one >>> can't stand Groovy. >> We need to reach at some for of (temporary) agreement. QE needs to continue >> developing tests and so far we are simply "stuck" in the middle of >> discussion >> whether to continue with current tooling or not. >> > > My current preference is - long term - using Java. > > IMO this does NOT need to be ported now, as we speak, but soon. Sounds like a plan. We'll continue sending PRs in Groovy and revisit the code early Sep then.

> > After my vacation (End of August / early Sep.) I am happy to help porting > the tests to Java, but not now. > > > -Matthias > > > >>> And that's the reason I strongly advocate for keeping it to Java - this >>> is a Groovy vs Java, while it should've been X vs Java - Scala specs2, >>> RSpec (via JRuby), Jasmine or Mocha (via DynJS or Rhino) - Heck, even >>> Clojure would be easier to work than Java. >> Cradle of best Czech beer for anybody who adds Arquillian support into >> Jasmine or Mocha ;-) >> >>> Unless we have a broad discussion over all those languages (which >>> honestly I don't think we have time for that) we should stick to the >>> lowest common denominator, which is (unfortunately) Java. >>> >>> fwiw, I can see the value of s/Groovy/dynamic JVM lang for tests/ - any >>> of them would fit the bill - what I can't let go is the partiality of >>> the debate. >>> >>> On Tue, Jul 16, 2013 at 01:03:43PM +0200, Karel Piwko wrote: >>>> Hi, >>>> >>>> let me summarize the discussion from previous threads: >>>> >>>> What were testing requirements? >>>> * Do not mock >>>> * Cover both backend and frontend testing at the same time >>>> * Control test env from tests/Maven, so it runs on both CI and local >> machine >>>> without any setup required >>>> => Those 3 requirements limited us to use Arquillian >>>> * Cover unified push server specifications in readable way >>>> >>>> Why Groovy instead of Java? >>>> + Better support for JSON >>>> + Spock provides very nice BDD support >>>> + Still supports anything Java would do >>>> >>>> What problems we faced with Groovy? >>>> - Needs specific compiler - solved, configured for tests only >>>> - Needs support in IDE - Intellij - ootb, Eclipse and NetBeans have >>>> plugins >>>> - Needs to be deployed in test deployment - not addressed now, >> prolongs test >>>> execution by few seconds per deployment >>>> >>>> What are currently raised concerns? >>>> - Different language for development and testing >>>> - Raises bar for newcomers willing to write tests >>>> >>>> Thank you for additional advantages, concerns or proving some of those >> are >>>> not valid. >>>> >>>> Karel >>>> _______________________________________________ >>>> 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