Did Geb 5 change the order in which GebConfig.groovy is run?

[jc]

I am currently in the process of trying to update our project's from 4.0 to 5.1.  Currently on 4.0, we have a BaseTest class that extends GebReportingSpec and then all other test classes extend BaseTest.   In GebConfig.groovy, I have some lines that set different environment variables such as "runOnGrid" which is true/false, "browserType" which is a string, "env" which is the environment, etc....

We have some @IgnoreIf statement in our code to prevent running on certain environments like Production.  For example, we have an entire test class "TestClassA" that can run on pre-prod but we want to ignore the whole class for Prod.  We put an @IgnoreIf annotation on the class that looks at `System.getProperty("env") == "prod"`

This is currently working beautifully in 4.0.  However in 5.1 this is no longer working as  `System.getProperty("env")` is coming back as null along with all of the other variables we have set.  These variables are set by the time we hit the setupSpec() in BaseTest, but they are null prior to that when they were not before.  So it seems like before 5.0, GebConfig.groovy was getting run earlier is the compilation process perhaps?  I guess I don't know how it all works, but I just know now that with Geb 5 this method is no longer working for us.  

[jc]

Ok, I think I know what happened.  It's nothing Geb 5 changed.  I worked with Leonard Brünings as he helped me clean up some bad code while figuring out another issue.  One the lines I cleaned up was an unused line in the BaseTest: static Browser browse = new Browser()

With this line in place, even though it is unused anywhere, it seems as thought the env variable set in GebConfig are evaluated in time.  Without this line, the GebConfig variables are not evaluated in time.  I don't fully understand it.  I definitely want to have good code (I am aware setting env variables in GebConfig is "bad", but it's working for us).   So if there is another way we can achieve these @IgnoreIf method getting evaluated at the right time I am all for it.  Any insights?

[Marcin Erdmann]

GebConfig.groovy is usually evaluated when geb.ConfigurationLoader.getConf() is executed which for example happens inside of the parameterless constructor for geb.Browser. If you want to have GebConfig.groovy evaluated early on as part of executing tests then one thing that comes to mind with the setup you describe is to put new ConfigurationLoader().conf in a static initalization block of BaseTest.

--
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 geb-user+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/geb-user/f66cd19f-fe4b-4411-817a-1c4f97d6dc24n%40googlegroups.com.

[Alexander Kriegisch]

Hi Marcin.

I am not sure you are following the Spock chat on Gitter. While talking to Jeremy there, I was looking into how Geb actually works. Result (I wrote much more there): It is a simple global Spock extension. But to my surprise, the Geb config is not read just once during extension start, but quite often, e.g. whenever the Geb test manager calls getBrowser in beforeTest, i.e. for each feature method in a Geb spec. By printing callstacks from the Geb config, this is easy to see.

So my question is: What is the reason for that? Are you expecting cases in which the Geb config changes during a JVM session? The driver configurations for multiple environments are closures, so they can be evaluated without re-reading the file. Any system properties defined there should also not depend on dynamic things like time stamps, random values or whatever.

Cheers

--
Alexander Kriegisch
https://scrum-master.de

To view this discussion on the web visit https://groups.google.com/d/msgid/geb-user/CA%2B52dQR8S536Wopv0-aajsjuSvD2tdiy2Mup2LJpqsoG-ZVgnw%40mail.gmail.com.

[Marcin Erdmann]

Alexander, your following statement:

But to my surprise, the Geb config is not read just once during extension start, but quite often, e.g. whenever the Geb test manager calls getBrowser in beforeTest, i.e. for each feature method in a Geb spec

is not completely precise. Geb config is read whenever ConfigurationLoader.getConf() is called. It happens to be called via the parameterless constructor of Browser, which in turn is called for the first time getBrowser() is called on an instance of GebTestManager. 

All that aside, yes, Geb config is definitely read more often than it needs to be. There will definitely be a performance penalty to parsing and executing that script for every single test but this has worked like that since forever (I started contributing to Geb in 2010 and it's how it was back then) so changing this will be a breaking change. It will be fairly easy to change to only load the config once per GebTestManager instance but that would be a breaking change so would need to be done only in Geb 6 which might be coming soon due to switching to Selenium 4 which is not backwards compatible. If you feel like this would be worthwhile to change, Alexander, then please open an issue in the tracker and I will schedule it for Geb 6.

To view this discussion on the web visit https://groups.google.com/d/msgid/geb-user/20220331091724.E73B378C0999%40dd19710.kasserver.com.

[Alexander Kriegisch]

I can create an issue tomorrow or so. I might even create a PR, if you like. It might not be a great PR, given the fact that I do not know the Geb source code well and never have contributes to the project before, but I can give it a try. At least you have something to work with, or we have something to discuss and, if necessary, throw away and re-do better. Would a PR go on the current main branch or are you planning a special branch for the work on Geb 6?

--
Alexander Kriegisch
https://scrum-master.de

 

Marcin Erdmann schrieb am 12.04.2022 22:31 (GMT +07:00):

But to my surprise, the Geb config is not read just once during extension start, but quite often, e.g. whenever the Geb test manager calls getBrowser in beforeTest, i.e. for each feature method in a Geb spec

 

is not completely precise. Geb config is read whenever ConfigurationLoader.getConf() is called. It happens to be called via the parameterless constructor of Browser, which in turn is called for the first time getBrowser() is called on an instance of GebTestManager. 

 

All that aside, yes, Geb config is definitely read more often than it needs to be. There will definitely be a performance penalty to parsing and executing that script for every single test but this has worked like that since forever (I started contributing to Geb in 2010 and it's how it was back then) so changing this will be a breaking change. It will be fairly easy to change to only load the config once per GebTestManager instance but that would be a breaking change so would need to be done only in Geb 6 which might be coming soon due to switching to Selenium 4 which is not backwards compatible. If you feel like this would be worthwhile to change, Alexander, then please open an issue in the tracker and I will schedule it for Geb 6.

 

On Thu, Mar 31, 2022 at 10:17 AM Alexander Kriegisch <alex...@kriegisch.name> wrote:

I am not sure you are following the Spock chat on Gitter. While talking to Jeremy there, I was looking into how Geb actually works. Result (I wrote much more there): It is a simple global Spock extension. But to my surprise, the Geb config is not read just once during extension start, but quite often, e.g. whenever the Geb test manager calls getBrowser in beforeTest, i.e. for each feature method in a Geb spec. By printing callstacks from the Geb config, this is easy to see.

So my question is: What is the reason for that? Are you expecting cases in which the Geb config changes during a JVM session? The driver configurations for multiple environments are closures, so they can be evaluated without re-reading the file. Any system properties defined there should also not depend on dynamic things like time stamps, random values or whatever.

 

Marcin Erdmann schrieb am 31.03.2022 02:45 (GMT +07:00):

[Marcin Erdmann]

I replied on the issue. Thanks for opening it, Alexander.

Marcin

--

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 geb-user+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/geb-user/20220412162153.C862478C0ECE%40dd19710.kasserver.com.