+1 for Spock and Geb.
I have been using Spock and Geb for some time now. Being both in Groovy saves
you a lot of time.
One of the concerns that I have with Geb is unstable tests which seems to be
related to WebDriver but, for some reason, are more visible with Geb.
BTW Spock extensions are r
Already voted :)
On Jul 31, 2013, at 12:30 PM, Massimo Lusetti wrote:
> On Wed, Jul 31, 2013 at 6:52 PM, Lenny Primak wrote:
>
> As long it's a 404 in both production and development mode I'm fine with
>> that.
> BTW anyone interested in this could go to the issue page on Jira and vote
> for it
On Wed, Jul 31, 2013 at 6:52 PM, Lenny Primak wrote:
As long it's a 404 in both production and development mode I'm fine with
> that.
>
>
BTW anyone interested in this could go to the issue page on Jira and vote
for it.
--
Massimo Lusetti
As long it's a 404 in both production and development mode I'm fine with that.
On Jul 31, 2013, at 11:42 AM, Massimo Lusetti wrote:
> On Wed, Jul 31, 2013 at 6:31 PM, Lance Java wrote:
>
> You can have your cake and eat it!
>>
>> It's valid for a 404 response to have a body and a content ty
On Wed, Jul 31, 2013 at 6:31 PM, Lance Java wrote:
You can have your cake and eat it!
>
> It's valid for a 404 response to have a body and a content type.
>
Fine, let's put it this way: In dev mode is valuable to have and
"explanation" of what happened while in prod mod simply a 404 so it could
b
As I see its not the same at all.
The exception report behavior is the same only the text is different.
Here you are proposing completely different error and behavior in production
and in development. Intent is not the same.
What if someone intercepts all exceptions and emails production suppor
I'm open to anything and I'll try to look at your links. That being said,
web applications are all about integration, and I just don't have
confidence unless it is tested end-to-end using a real browser.
On Wed, Jul 31, 2013 at 8:21 AM, Martin Grigorov wrote:
> Hi,
>
> Have you considered pure J
You can have your cake and eat it!
It's valid for a 404 response to have a body and a content type.
On 31 Jul 2013 17:07, "Massimo Lusetti" wrote:
> On Wed, Jul 31, 2013 at 6:00 PM, Lenny Primak >wrote:
>
> I would say no.
> > The behavior in production.and development mode differences in gener
On Wed, Jul 31, 2013 at 6:00 PM, Lenny Primak wrote:
I would say no.
> The behavior in production.and development mode differences in general is
> a bad idea. This will preclude valid testing in development.
>
>
It would be the same situation of the ExceptionReport page and it would go
hand to han
I would say no.
The behavior in production.and development mode differences in general is a bad
idea. This will preclude valid testing in development.
On Jul 31, 2013, at 10:51 AM, Howard Lewis Ship wrote:
> Could this be a case where we want one behavior in development (a Tapestry
> error)
About Geb,
I still have aggravations using Geb, but it is significantly better than
Selenium.
The page and module system is terrific for creating DRY and maintainable
tests.
The wait system addresses your concern; essentially, Geb runs a retry loop
until a condition is met, and fails if the cond
On Wed, Jul 31, 2013 at 5:51 PM, Howard Lewis Ship wrote:
Could this be a case where we want one behavior in development (a Tapestry
> error) and another in production (a 404 status)?
>
>
Yes, definitely a valid case.
--
Massimo Lusetti
Could this be a case where we want one behavior in development (a Tapestry
error) and another in production (a 404 status)?
On Wed, Jul 31, 2013 at 8:38 AM, Dimitris Zenios
wrote:
> +1
>
>
> On Wed, Jul 31, 2013 at 6:21 PM, Lenny Primak >wrote:
>
> > Big +1 for me. I currently use the following
+1
On Wed, Jul 31, 2013 at 6:21 PM, Lenny Primak wrote:
> Big +1 for me. I currently use the following code in the index page to
> work around this issue:
>
> 8 /**
> 9* Restore 404 Not Found errors
> 10 * @param context
> 11 * @return
> 12 */
My 2p.
I have had major headaches in the past maintaining selenium tests. The main
problems are getting selenium to wait until the client is in a certain
state. I found checking for AJAX responses or other custom conditions to be
very flaky. Sometimes the only solution was to Thread.sleep() which
Big +1 for me. I currently use the following code in the index page to work
around this issue:
8 /**
9* Restore 404 Not Found errors
10 * @param context
11 * @return
12 */
13 HttpError onActivate(EventContext context)
14 {
15
Hi,
Have you considered pure JavaScript based testing ?
It is much faster than WebDriver based and much closer to the real world.
1. Blog -
http://wicketinaction.com/2012/11/javascript-based-functional-testing/
2. Tests -
https://github.com/apache/wicket/tree/master/wicket-examples/src/main/webap
Hi devs,
I would like to have
https://issues.apache.org/jira/browse/TAP5-2070closed before 5.4 will
go to beta stage.
I mainly want to decide if the current behavior is acceptable for the
majority or we need to change it, then we can discuss on the implementation.
Please comment.
--
Massimo L
I have never been able to get any selenium tapestry tests to run on my Mac at
all BTW.
Something has to do with firefiox version or something.
So, even the proverbial 'patch with tests' isn't possible for me.
I really don't mind the bleeding edge technology though.
On Jul 31, 2013, at 9:10 AM
On Wed, Jul 31, 2013 at 4:10 PM, Ulrich Stärk wrote:
One reason I haven't contributed much in terms of code for quite some time
> is the ever changing
> technology stack Tapestry is built with. We have an increasingly complex
> stack of bleeding-edge
> tools and technologies that I simply lack th
One reason I haven't contributed much in terms of code for quite some time is
the ever changing
technology stack Tapestry is built with. We have an increasingly complex stack
of bleeding-edge
tools and technologies that I simply lack the time of keeping up with.
I have the feeling that this migh
On Tue, Jul 30, 2013 at 11:50 PM, Howard Lewis Ship wrote:
One thing I've been saying in some of the bugs I've been closing is my
> desire to get out of the testing side of things. I have no desire to
> maintain the existing TestNG, EasyMock, and Selenium support code ... you
> may have noticed th
22 matches
Mail list logo