Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tests are not rerun if failure because of WaitTimeoutException #3

Open
levsa opened this issue Aug 26, 2015 · 8 comments
Open

Tests are not rerun if failure because of WaitTimeoutException #3

levsa opened this issue Aug 26, 2015 · 8 comments

Comments

@levsa
Copy link

levsa commented Aug 26, 2015

Is it correct that timeout failures aren't caught by this extension and retried? I get a test that fails with

geb.waiting.WaitTimeoutException: condition did not pass in 20.0 seconds (failed with exception)

which does not cause reruns.

@anotherchrisberry
Copy link
Owner

It should be catching and retrying those tests. Which version of Spock are you running? The 0.1 release should work with Spock 1.0, but if you're using 0.7, you'd have to use the code in the initial commit.

@levsa
Copy link
Author

levsa commented Aug 26, 2015

Using spock 1.0.
ons 26 aug 2015 kl. 17:36 skrev Chris Berry [email protected]:

It should be catching and retrying those tests. Which version of Spock are
you running? The 0.1 release
https://github.com/anotherchrisberry/spock-retry/releases/tag/0.1
should work with Spock 1.0, but if you're using 0.7, you'd have to use the
code in the initial commit.


Reply to this email directly or view it on GitHub
#3 (comment)
.

@levsa
Copy link
Author

levsa commented Aug 26, 2015

Just realized the timeout happens in an "at" section called from a base
spec setup method.
ons 26 aug 2015 kl. 17:39 skrev Levon Saldamli [email protected]:

Using spock 1.0.
ons 26 aug 2015 kl. 17:36 skrev Chris Berry [email protected]:

It should be catching and retrying those tests. Which version of Spock
are you running? The 0.1 release
https://github.com/anotherchrisberry/spock-retry/releases/tag/0.1
should work with Spock 1.0, but if you're using 0.7, you'd have to use the
code in the initial commit.


Reply to this email directly or view it on GitHub
#3 (comment)
.

@anotherchrisberry
Copy link
Owner

Ah, yeah, looks like it doesn't re-run setupSpec methods in superclasses.

Shouldn't be that hard to implement, but I probably will not get to it until this weekend.

@levsa
Copy link
Author

levsa commented Aug 27, 2015

I think the retry code even doesn't catch errors in setup methods? Here is the full stack trace:

geb.waiting.WaitTimeoutException: condition did not pass in 20.0 seconds (failed with exception)
    at geb.waiting.Wait.waitFor(Wait.groovy:124)
    at geb.waiting.WaitingSupport.doWaitFor(WaitingSupport.groovy:109)
    at geb.waiting.WaitingSupport.waitFor(WaitingSupport.groovy:67)
    at geb.waiting.WaitingSupport.waitFor(WaitingSupport.groovy:63)
    at geb.Page.waitFor(Page.groovy:81)
    at com.iipax.geb.pages.LoggedInPage._clinit__closure1(LoggedInPage.groovy:7)
    at com.iipax.geb.pages.LoggedInPage._clinit__closure1(LoggedInPage.groovy)
    at geb.Page.verifyThisPageAtOnly(Page.groovy:187)
    at geb.Page.verifyAt(Page.groovy:146)
    at geb.Browser.methodMissing(Browser.groovy:203)
    at geb.navigator.NonEmptyNavigator.click(NonEmptyNavigator.groovy:467)
    at geb.content.TemplateDerivedPageContent.click(TemplateDerivedPageContent.groovy:111)
    at com.iipax.geb.LoggedInGebSpec.setup(LoggedInGebSpec.groovy:25)
Caused by: Assertion failed: 

$("#header-user-menu .ii-logout-link")
|
[]

    at com.iipax.geb.pages.LoggedInPage._clinit__closure1$_closure3(LoggedInPage.groovy:7)
    at com.iipax.geb.pages.LoggedInPage._clinit__closure1$_closure3(LoggedInPage.groovy)
    at geb.waiting.Wait.waitFor(Wait.groovy:113)

LoggedInGebSpec is the base class of my current Spec, and the timeout occurs in its setup()

@levsa
Copy link
Author

levsa commented Aug 27, 2015

I tried to fix this but no success. There are interceptors in SpecInfo, e.g. iterationInterceptor, but failures from tests does not propagate to them. There is however setupInterceptors which might work, but then one has to retry each setup method on its own, which wouldn't work.

@anotherchrisberry
Copy link
Owner

Can you give this a shot and see if it handles the issues you're seeing?
#5

@levsa
Copy link
Author

levsa commented Aug 31, 2015

It does catch the error and retries, but doesn't cleanup and setup everything from start, i.e. no navigation happens while retrying.

I guess the problem is to know which cleanup and setup-methods have been run before the failure and what should be done before rerunning.

I've solved the shakyness that caused the failure in the setup for now, so this can wait for a better solution from spock framework.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants