Steve, Thanks for providing more context, it made things clearer for me.
I believe that if you use the workaround which amounts to modifying the common base class and which I provided previously but without modifying cacheDriver configuration setting then things will work as expected if you use CachingDriverFactory.clearCacheAndQuitDriver() in some of the tests like you did prior to the attempted upgrade. I'm not sure if you are already aware but if you need to clear cookies on multiple domains after some of the tests then you can use https://gebish.org/manual/current/api/geb/Browser.html#clearCookies(java.lang.String) for that which will save you from having to restart the browser. Depending on page load times for the domains you need to clear cookies on, how many of these domains there are and which driver(s) you are using it might be quicker or not compared to discarding the browser completely. Marcin On Mon, Oct 24, 2022 at 5:44 PM Steve Hillman <[email protected]> wrote: > 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 > <https://groups.google.com/d/msgid/geb-user/CAPhyn93EO4mZft5UXkJFzjRwA5Nk1JGKT9O8Wczhq7SFd_pFZQ%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/CA%2B52dQT%3DMmHo2%3D7oGgK7dtRbp7yw%2Bj9XwAbrzqXPPxpt095LsA%40mail.gmail.com.
