Thanks, Marcin, for your detailed explanation You are, of course, right - I reviewed our code and found that we were previously calling CachingDriverFactory.clearCacheAndQuitDriver() from within an overridden resetBrowser() after *some* tests.
So really, the core issue is that if we call quit() on the caching driver, a new driver won't be spawned for the next test, whereas it was in Geb 1, and the docs say it should. I'll see if I can figure out a way around that, but I'm open to ideas. I tried using the code snippet you suggested, which works (we do have a superclass so this was easy to test) - the one issue is that we only want to quit and relaunch the browser sometimes - not for every test. It would be great if we could call quit() when needed and then do whatever is necessary to launch a new browser instance at that point (if you're curious, the reason we need to quit the browser is because we're testing using third-party logins to a site (e.g. "Login using Google, Login using Facebook"). When you login using a third party, it can create cookies in all sorts of domains, so we can't reliably delete them with clearCookies()). On Sun, Oct 23, 2022 at 1:34 PM Marcin Erdmann <[email protected]> wrote: > Hi Steve, > > Migrating from 1.1.1 to 6 sounds ambitious but not insurmountable. I don't > think there were that many significant breaking changes between these > versions. > > I will respond inline cause there are multiple concerns. > > On Fri, Oct 21, 2022 at 5:45 PM Steve Hillman <[email protected]> > wrote: > >> Under Geb 1, the behaviour was to quit and relaunch the browser for every >> test, unless resetBrowser() was overridden to do nothing. It was a bit >> slow, but it was effective. >> > > Just FWIW, this is not the default behaviour under Geb 1. Driver instance > has been cached in Geb since I remember and definitely prior to Geb 1 so > this behaviour will have to do with something specific to your project's > setup. > > Under Geb 6, the driver is cached and this is causing problems with some >> tests. I've tried numerous techniques to clear cookies but none have >> worked. >> > > Unless configured not to using autoClearCookies config property, cookies > are cleared after each test in Geb by default. In the latest versions it > happens in geb.test.GebTestManager.resetBrowser(). I have never experienced > this not to work so I'm wondering what makes you believe that cookies are > not cleared for you between tests and why you believe you need to restart > the browser after each test to overcome it. If your tests are not dealing > with multiple domains then you should not have to deal with managing > cookies state at all if using the default configuration which includes > driver instance caching. > > >> I tried using "quitDriverOnBrowserReset = true" and ran into this issue: >> https://github.com/geb/issues/issues/657 . I tried the workaround, >> setting "cacheDriver = false" but then ran into my final problem: when the >> browser is quit, it's not respawned for the next test. Instead, I get the >> same error as issue 657 - "Session ID is null. Using WebDriver after >> calling quit()?" >> > > So https://github.com/geb/issues/issues/657 is more of a documentation > issue - it's not clear that "quitDriverOnBrowserReset = true" will lead to > that error if driver caching is enabled. On the other hand just setting > "cacheDriver = false" even without modifying quitDriverOnBrowserReset > should in Geb 6 give you the behaviour you are after of restarting the > browser after each test. Unfortunately the fix for > https://github.com/geb/issues/issues/660 which was to add configuration > script execution caching caused a bug leading to the error you are seeing. > I've therefore created https://github.com/geb/issues/issues/677. > > One way to work around the bug that comes to my mind is to add the > following superclass for all of your tests: > > class WorkAroundGeb677Spec extends GebReportingSpec { > > private final static GebTestManager TEST_MANAGER = new > SpockGebTestManagerBuilder() > .withBrowserCreator { new Browser() } > .withReportingEnabled(true) > .build() > > GebTestManager getTestManager() { > TEST_MANAGER > } > } > > Depending on whether you already have a single superclass for all of your > tests this might or might not be feasible workaround for you. > > Marcin > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Geb User Mailing List" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/geb-user/Izdvu9zLLLY/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/geb-user/CA%2B52dQQnbteUkh3Utz%3D%3DraqZToZvtY2XyRmd79u8XFKX%2B5-CQg%40mail.gmail.com > <https://groups.google.com/d/msgid/geb-user/CA%2B52dQQnbteUkh3Utz%3D%3DraqZToZvtY2XyRmd79u8XFKX%2B5-CQg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Geb User Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/geb-user/CAPhyn93EO4mZft5UXkJFzjRwA5Nk1JGKT9O8Wczhq7SFd_pFZQ%40mail.gmail.com.
