On 07/16/2013 07:09 AM, Matthias Wessendorf wrote:

Hi Karel,

thanks for starting the thread and summarizing all the facts/statements from the previous discussion!

On Tue, Jul 16, 2013 at 1:03 PM, Karel Piwko <kpiwko@redhat.com> 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

Not really, if you are using Maven as your project format then the IDEs really don't have to do any work. The latest NetBeans has not craptacular Groovy out of the box as well.

- 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

Why is this a concern?

- Raises bar for newcomers willing to write tests

Other than ending a FooTest in .groovy or .java how does it actually raise the bar?

that's the 'concerns' I share as well: it a little burden on getting back contributions, since the source of the server is java.

Also, what would happen if others decide let's add Ruby and also Perl for some sort of tests? That would mean a language nightmare, IMO :)

We reject the PR. Groovy is a much "easier" language than Java. Sure it will allow people to write some particularly hellish code, but we just punt those PRs.

Punting the PR is also the answer for what happens if someone adds Ruby or Perl.

Thank you for additional advantages, concerns or proving some of those are not
valid.

Pros of Groovy:
* Built in examples of how to call the code from a Groovy based application.
* It gives us a carrot to hang in front of community members who might not want to write Java or who want to stretch their polyglot legs.

Cons of Groovy:
* Language is slippery. Lots of ways to do something which could be quite abstract or opaque.
* If we use indy then we are committing to Java 7+
* It does require us to make some annoying trade offs w.r.t simplicty of our build.
* One more point of failure in a build

Karel
_______________________________________________
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