Geb won't help much in your case. The biggest 'problem' is that Tapestry now uses a lot of different technologies: Code in Java, tests in Java and Groovy, a lexer in antlr, JavaScript generated from CoffeeScript, etc. The build is extremely complex due to the mixture of different technologies and accordingly fragile.
Uli On 2013-11-04 22:37, Luca Menegus wrote: > May I disagree? > I'am trying to contribute a (trivial) patch related to Beandisplay and > reported in user mailing list. > The most difficult task was not spotting the bug but: > > 1. setting up tapestry in eclipse > that was *not* easy took more than half an hour (not counting download time). > The doc is basically right. That is if you follow it you get the compile env > setup correctly. > But why should I mess with eclipse classpath in 2013? or change the source > version (1.5 to 1.6)? I think that we have the tool to make at least major > dev env set up correctly out of the box. > IMHO this is the first obstacle to the casual contributor. I was *really* > tempted to just fork tapestry locally and simply report the issue. > > 2. running test in dev environment > If you develop a patch and are willing to provide an integration test case > you should be able to run a subset of the integration test cases out of the > box. > I use maven and junit so I'm not confident with gradle, gradle eclipse > plugin, testng and eclipse testng plugin. > I *really* think this is mainly a doc issue but still I took me 10 times more > to run the integration test than to write them. > Ok development is hard and I should do my homework etc etc (and I did them I > think) but having guides, examples, how-tos on testing will make it easier > for people to contribute decent patches > > 3. running the whole test suite from gradle > I use Centos 6.4 as my desktop env so this might not apply to other > environments but my experience is that if you wanted the whole tests to run > smoothly you should really go away and have a coffee. > Even changing focus to any other window make some random test fail (note that > I browse with chrome and run tests with firefox). > I also read that you need to have an old copy of firefox to run the test > suite as it won't run on newer versions... I can confirm that: I have a > separate fully updated f19 system where the tests simply fail. > > > I want to stress this out: *I think tapestry is super*! Really! We're using > tapestry extensively, and it's fast, reliable and easily customizable. If you > have some dev experienced with inner t5-lore you can have junior devs writing > pages in hours... > > what I wanted to say is that having a: > - easier dev-env set up > - more immediate way to run test from dev env > - more robust ci test env > would be a great pay-off. > > So if a move to WebDriver (and geb) would go in such direction please go > haed! I can't assure you that I'm going to contribute something back but at > least I'll try (really) > > Best regards, > Luca > > > > ----- Original Message ----- >> From: "Howard Lewis Ship" <[email protected]> >> To: "Tapestry development" <[email protected]> >> Sent: Monday, November 4, 2013 9:24:11 PM >> Subject: Re: time to switch to Selenium 2? >> >> If we switch away from the legacy Selenium support, then it will be time to >> rewrite the test suites in Geb. That would be great ... but it's a huge >> amount of effort without a lot of payoff from the end-user point of view. >> >> >> On Mon, Nov 4, 2013 at 10:54 AM, Ulrich Stärk <[email protected]> wrote: >> >>> Oh never mind. We are already at Selenium 2 but not using the WebDriver >>> API. Need to investigate >>> further. >>> >>> Uli >>> >>> On 2013-11-04 19:39, Ulrich Stärk wrote: >>>> I'm running into problems with Selenium where the latest versions of >>> Firefox aren't supported >>>> anymore and certain actions don't trigger the corresponding events in >>> Chrome (e.g. onchange when >>>> selecting an element in Palette's available list). >>>> >>>> Switching to Selenium 2 is going to be a major pain. It will break a lot >>> of the existing tests and >>>> from the little experience I've had with it, it is very different from >>> Selenium 1 and certain things >>>> can't even be done with it anymore. I'd therefore suggest to create a >>> compatibility layer to allow >>>> existing tests coded against SeleniumTestCase to continue to run. >>>> >>>> What do you think? >>>> >>>> Uli >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> >> -- >> Howard M. Lewis Ship >> >> Creator of Apache Tapestry >> >> The source for Tapestry training, mentoring and support. Contact me to >> learn how I can get you up and productive in Tapestry fast! >> >> (971) 678-5210 >> http://howardlewisship.com >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
