Geb overhead ... and performance issues ...

[Arvid Jedlicka]

We have created two Spock tests, one using Geb and another using a home grown 'framework' that calls Selenium directly.

Both tests are identical in that they log on to the system, add a record, retrieve a record, update a record and then logs off.

Both tests are identical in that they both use the same IE 32 bit web driver to call IE 11 on the same Windows 7 64 bit machine.

Both "page descriptions" are identical in that they both define the elements on the page by id wherever possible ... i.e. birthDate { $('input', id: 'birthDate') } in the case of Geb and a rather obtuse syntax and semantics for the home grown 'framework'.

The significant difference between the tests is that the Geb test uses the straight forward 'birthdate = "11111956" to set the value with Geb performing all of the 'magic' behind the scenes while our framework test calls a method (does not make for an easy to read test) that goes directly against the Selenium WebDriver to (a) do a findElement() and then a sendKeys() to the element.

Other than the above mentioned "Geb '='" vs the ugly method call the tests go to the same pages, set the same values to the same fields, etc.

There is very observable difference in speed when watching the browser as the tests run, some of it related to the 'key strokes' and some of it related to pauses between the time a page appears and the time activity starts happening.

We tried (cache: true) on all of the attributes on the Geb page ... birthdate(cache: true) { $('input', id: 'birthDate') } ...  but it did not seem to make a difference in the 'Add' case [expected because it was the first time Geb would have seen the page so nothing would have been cached] and then failed when it got to the Retrieve part of the test of the same page claiming that an attribute successfully referenced during the Add was "Element is no longer valid".

We were expecting (and willing to accept) a performance hit for the convenience of the Geb syntax and semantics but we are confounded by the size of the penalty.

The home grown test case completes in 14 seconds while the Geb version completes in 36 seconds.

Obviously "over twice as long"  is more than we are willing to accept.

I am looking for any suggestions as to what we have done wrong as it does not make any sense that Geb would add that much overhead.

As a side note, we have a tool that generates 95% of the Geb page code based on the page HTML. If there is some other way of creating the template other than $('input', id: 'xxxx') } that would provide a much faster test we can easily change our generator to write a 'really ugly but super fast' content template.

Thanks,

Arvid

[J. David Beutel]

Have you tried using $('input#birthDate')?

--
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 post to this group, send email to geb-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/geb-user/19305c01-f339-4c75-ad63-efcedc900edb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Brian Kotek]

There are some obvious questions up front, such as "is the custom framework built with Groovy?", "are they both using the same version of Webdriver?" (Geb uses Webdriver, not Selenium), "is the delay caused by Geb's default wait time (for timeout and retry interval), or any customizations you've made to those settings?", "is startup time being factored in?", etc. 

Beyond that, it's hard to say. Obviously Geb is almost certainly doing (and capable of doing) far more than any homegrown framework. It's possible that the larger size, dynamic code, AST transforms and so on are actually adding onto the execution time.

That said, large suites of functional tests are generally run pretty rarely. I would argue that how long they take to run really pales in comparison to making it easy to write lots of good tests. For what it's worth, I've never had any problems with the time taken for Geb tests, and I've got some fairly large suites floating around on various projects.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/geb-user/55664810.2030904%40getsu.com.

[Arvid Jedlicka]

Thanks for the suggestion. First think in the morning!!

[Arvid Jedlicka]

The custom framework is a Groovy wrapper over Selenium. It was suppose to hide the Selenium complexity for the limited amount of functionality we needed from Selenium.

They both are using the same Selenium InternetExplorerDriver.exe

I've not set any configuration options related to wait or retry. I had assumed they were related to 'waiting for a page to be established' in the browser and that seems to happen very quickly in both systems. I also assumed that a wait time was a maximum and if the page was ready to go before the wait time had expired then Geb would move on immediately.

Startup 'time before the browser pops up' seems to be the same in both cases. There does seeM to be a visual delay moving from field to field in the screen and Geb does not enter keystrokes as quickly as the home grown version.

Though I agree that large tests are not run frequently the goal is to make a large number of small tests part of our CI build. The team is very concerned about 'at least twice as long'.

Thanks,
Arvis

[Brian Kotek]

One other thing to check is try it in Chrome or Firefox, to see if it's related to IE. Since you're on IE 11, it's probably not, but it wouldn't hurt to confirm.

--
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 post to this group, send email to geb-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/geb-user/1fdc5ca8-b4ed-4064-9575-7138bfa707f4%40googlegroups.com.

[Brian Kotek]

In fact, it wouldn't hurt to try it with PhantomJS either (since I assume you'd want to use a headless browser in a CI environment anyway).

[Marcin Erdmann]

Any chance that you could share your Geb code for me to look if there are some obvious performance issues with it?

Geb does more calls to WebDrvier's wire protocol than is needed at the moment unfortunately. This is down to how navigator factories are currently implemented and I would like to improve it: https://github.com/geb/issues/issues/306, https://github.com/geb/issues/issues/333. There is also an issue about translating maps passed to $() method into pure css selectors (https://github.com/geb/issues/issues/280) instead of using the text selector passed and then iterating over the returned result and looking for attribute matches on the Geb side. Some of the elements passed in these maps (namely id and class) are already translated.

Also, are you using 0.10.0? There was a really nasty performance bug in versions prior to 0.9.0: https://github.com/geb/issues/issues/223.

There definitely is some room for improvement here but Geb will always be slightly (twice as slow is not acceptable, I agree) slower than a homegrown simplistic solution that is not as rich in features. With simplicity provided by Geb there comes a price. It's another abstraction layer on top of WebDriver, you won't get it for free.

--
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 post to this group, send email to geb-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/geb-user/1fdc5ca8-b4ed-4064-9575-7138bfa707f4%40googlegroups.com.

[Arvid Jedlicka]

Brian,

Thanks for your suggestions.

I'd try other browsers but both tests are using the same Selenium InternetExplorerDriver.exe so I feel comfortable that the differences are related to the Geb - Direct Selenium differences.

I suspect that the Chrome and Firefox drivers will be faster for both Geb and Direct Selenium but the application is 'in house', IE 11 is the only officially supported browser for now and therefore the testing will be against InternetExplorerDriver.exe. 

[Arvid Jedlicka]

Regretfully I can not share the code.

I know it is difficult to make recommendations without the code but it is not a complex test.

The page simply defines 23 fields by id, 5 by name, one by text and 1 by title. Of the 30 fields 7 are marked as (required: false). All 7 of these fields are "read only" ... application status, etc.

The Spock test is a simple "log in and test to be sure we're on the right page" setupSpec feature, a navigation feature that goes to and validates the correct page, an Add feature that clicks on the clear button, set the value of 11 elements, selects the "add" option from an action drop down and then clicks on the "Perform Action" button. The feature then checks that page, the status on the page and captures the Id of the record added. This feature is followed by a "Retrieve" feature that looks like this:

    def "Retrieve xxxx"() {

        when: "Retrieve xxxx details based on Added record"

        XXXXXX.with {

            clear.click()

            xxxxID = whereXxxxId

            action = 'getXXXX'

            performAction.click()

        }

        then: "Confirm page/data"

        at XXXX

        and:

        XXXX.with {

            whereXxxxId  == xxxxID.value()

            createUserID.value()

            createDateTime.value()

        }

        where:

        whereXxxxId << xxxxIdsThatWereAdded

    }

This is followed by a Update feature that is as complex as the Retrieve ... i.e. I'm not sure how much less code I can write and it actually do something meaninful :-}

I am using 0.10.0

Based on Brian's suggestion and looking at the 0.10.1 [which I can not use until it is released] documentation and seeing the "By.xxx" selector support I changed how I find an element.

My closures now look like ...

birthDate { $(browser.getNavigatorFactory().createFromWebElements([browser.driver.findElement(By.id('birthDate'))])) }

Side note ... this does meet the '''really ugly but reasonably fast' content template" option I mentioned in my first post ;-}

This brought the time down from the original 36 seconds to 20 seconds so at least now we are in the same ball park and it may be palatable.

I realize it without the code it is difficult to make meaningful suggestions but any other suggestions ... possibly related to configuration of wait values [which I admit I am not confident in my understanding] or things that might influence implicit waits would be appreciated.

Thanks,

Arvid

[Arvid Jedlicka]

Marcin,

Just curious. Do you think the improvements with https://github.com/geb/issues/issues/306 and https://github.com/geb/issues/issues/333 will make a difference over the closure that I am currently using:

birthDate { $(browser.getNavigatorFactory().createFromWebElements([browser.driver.findElement(By.id('birthDate'))])) }

I am currently at "43% slower" ... 14 vs 20 seconds ... and that is a 'significant con' against the Geb solution. It has been suggested that I try the current 0.10.1 snapshot but I'm not optimistic about a performance improvement without 306 and 333 [and even with 306 and 303 I have no idea what to expect]. My closure would become less ugly:

birthDate { $(By.id('birthDate')) }

but I suspect that alone will not make a marked improvement in performance.

Thanks,

Arvid

On Thursday, May 28, 2015 at 3:11:12 AM UTC-5, Marcin Erdmann wrote:

...

[Marcin Erdmann]

On Thu, May 28, 2015 at 2:47 PM, Arvid Jedlicka <arvid.j...@gmail.com> wrote:

Regretfully I can not share the code.

That's a shame but we'll work with what we have.

 

The page simply defines 23 fields by id, 5 by name, one by text and 1 by title. Of the 30 fields 7 are marked as (required: false). All 7 of these fields are "read only" ... application status, etc.

Make sure that your css selectors are as specific as possible when you are selecting by text. So if say you're selecting paragraphs by text that live inside a div with some class when you want to do:

$("div.wrapper p", text: "find me!")

Because there is no support for selecting by text in CSS, what happens is Geb gets all elements matching the selector and then iterates over them and checks their text. Getting text of an element is a wire protocol call, which means the more items you have to iterate over (that is, the less specific your css "base" selector is) the more calls over the wire. In general selecting by text is convenient but slow and should be avoided if you can.

When selecting by name or title make sure that you don't use a map expression but that you put everything in the selector, so use:

$("div[title='foo']")

instead of

$("div", title: "foo")

which is prone to the same performance problem as selecting by text. After #280 is fixed there will be no difference between one or the other because the map expression will be translated to a css selector.

 

I am using 0.10.0

Based on Brian's suggestion and looking at the 0.10.1 [which I can not use until it is released] documentation and seeing the "By.xxx" selector support I changed how I find an element.

0.10.1, which probably will be renamed to 0.11.0, will not be released for a while. I need to first finish migrating the Book of Geb to Asciidoctor and making all examples in it executable and then fix a bunch of issues.

 

My closures now look like ...

birthDate { $(browser.getNavigatorFactory().createFromWebElements([browser.driver.findElement(By.id('birthDate'))])) }

I think that you can simplify this to:

birthDate { $(browser.driver.findElement(By.id('birthDate')))

Be aware that the way you're accessing browser is not part of the public api so this might break in future releases. Hopefully this stuff will be fixed in 0.11.0 so that you will not have to do any of this anymore.

 

Side note ... this does meet the '''really ugly but reasonably fast' content template" option I mentioned in my first post ;-}

This brought the time down from the original 36 seconds to 20 seconds so at least now we are in the same ball park and it may be palatable.

It is very interesting that selecting using By.id("id") has different performance than selecting using By.css("#id"). I suspect that it might actually be specific to IE driver (which in general is way slower than other drivers). After #333 is implemented using $(id: "id") will be equivalent to using By.id("id"). In general, the support for using By for selecting was introduced to support selecting using xpath expressions if you really need/want to. I consider using By selectors with Geb not idiomatic so we will have to make sure that you can use the idiomatic way of selecting elements with Geb and not pay any performance penalty by doing so.

 

I realize it without the code it is difficult to make meaningful suggestions but any other suggestions ... possibly related to configuration of wait values [which I admit I am not confident in my understanding] or things that might influence implicit waits would be appreciated.

As long as your page is not dynamic and you're not using waitFor() {} or the "wait" content template option (or are you?) then waiting configuration will not affect you at all. 

 

[Marcin Erdmann]

On Thu, May 28, 2015 at 3:35 PM, Arvid Jedlicka <arvid.j...@gmail.com> wrote:

Marcin,

Just curious. Do you think the improvements with https://github.com/geb/issues/issues/306 and https://github.com/geb/issues/issues/333 will make a difference over the closure that I am currently using:

birthDate { $(browser.getNavigatorFactory().createFromWebElements([browser.driver.findElement(By.id('birthDate'))])) }

#306 will reduce the number of wire protocol calls in general which means that everything will be quicker. What we could do is I could implement it over the coming days and then ask you to try out a snapshot, what do you say?

#333 will mean that you will get the same performance with $(id: "birthDate") as you currently have with your crazy ugly selectors. So there will be no perf improvement from that over what you already have.

 

I am currently at "43% slower" ... 14 vs 20 seconds ... and that is a 'significant con' against the Geb solution. It has been suggested that I try the current 0.10.1 snapshot but I'm not optimistic about a performance improvement without 306 and 333 [and even with 306 and 303 I have no idea what to expect]. My closure would become less ugly:

birthDate { $(By.id('birthDate')) }

but I suspect that alone will not make a marked improvement in performance.

Yes, this will only make your selectors less ugly but you will not get any perf improvement from that compared to what you already have. 

[Arvid Jedlicka]

Marcin,

I'd be more than happy to try a snapshot except ...

I downloaded the current snapshot ... May 25th version ... and was not able to use it because, at least according to IntelliJ, my pages did not did not implement 8 waitFor methods. I am assuming geb.Page was suppose to implement those methods but did not. Or maybe I was missing something. My projects Maven dependencies include geb-core and geb-spock and possibly with the snapshot\0.11.0 there is another dependency that I need.

Assuming I can resolve that issue I'd be more than happy to continue performance comparisons.

Thanks,

Arvid 

[Arvid Jedlicka]

On Friday, May 29, 2015 at 7:11:33 AM UTC-5, Marcin Erdmann wrote:

Make sure that your css selectors are as specific as possible when you are selecting by text. So if say you're selecting paragraphs by text that live inside a div with some class when you want to do:

I am currently not using any css selectors, just the "ugly version" for all of my calls. By.id(), By.name() or By.linkText(). Those three currently cover all of my navigation needs. 

 

I think that you can simplify this to:

birthDate { $(browser.driver.findElement(By.id('birthDate')))

I will try that and report back. I had the extra factory call in there as I though I would be better of returning a geb Navigator rather than a Selenium WebElement .

Be aware that the way you're accessing browser is not part of the public api so this might break in future releases. Hopefully this stuff will be fixed in 0.11.0 so that you will not have to do any of this anymore.

Noted: I have been warned ;-}

It is very interesting that selecting using By.id("id") has different performance than selecting using By.css("#id"). I suspect that it might actually be specific to IE driver (which in general is way slower than other drivers). After #333 is implemented using $(id: "id") will be equivalent to using By.id("id"). In general, the support for using By for selecting was introduced to support selecting using xpath expressions if you really need/want to. I consider using By selectors with Geb not idiomatic so we will have to make sure that you can use the idiomatic way of selecting elements with Geb and not pay any performance penalty by doing so.

To be clear I never tried the By.css("#id") version. I simply went with what seemed to be the brutal "direct to the browser ugly version".

 

As long as your page is not dynamic and you're not using waitFor() {} or the "wait" content template option (or are you?) then waiting configuration will not affect you at all.

The pages are not dynamic. The only waitFor I have is on the 'at' statement ... which seems to make sense ... and having it there did not seem to make a timing difference and "you have to wait for the page to stabilize" seemed to make sense. Note that in the home grown framework we need to add a wait statement ... it is simply a "pause for xxx milliseconds" with no short circuit if the page actually is stabilized or any other tests ... before we can use a new page. 

All content has (cache: true, required: false) on them. The required: false made a slight improvement as the contents of the page is "validated" ... or not validated as the case may be ... when it appears in the browser. It made a second or two difference. The internal framework does not validate the page, simply fails if it can not find the attribute when it is referenced, so I wanted to make it an 'unsafe apples to unsafe apples' comparison. There is no documented coupling between cache and required ... i.e. if it's not required then is it still cached the first time it is used or is it not cached because the page is not scanned for required elements or ...? so I'm not sure if the cache:true has any effect or not. It does not appear to change the timing but cache: true does exhibit some instability that I had previously mentioned so the hypothesis is that "it does something'.

Thanks again for all the suggestions,

Arvid

[Arvid Jedlicka]

Tried the less ugly version and the performance was the same. Given that it is easier on the eyes I'll go with Marcin's version.

[Marcin Erdmann]

Don't download anything, just specify the snapshot repo and dependency on geb-core in your Maven project and let it resolve all the transitive dependencies.

Sorry for the small rant here ;) but why do people insist on downloading their jvm dependencies by hand in 2015 when there is a plethora of tools (Maven, Ivy, Gradle, ...) that know how to specify and resolve transitive dependencies out there? And you are already using Maven you say? ;)

--

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 post to this group, send email to geb-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/geb-user/1c988784-5769-4de0-89e9-54d763c218f6%40googlegroups.com.

[Marcin Erdmann]

On Fri, May 29, 2015 at 3:15 PM, Arvid Jedlicka <arvid.j...@gmail.com> wrote:

On Friday, May 29, 2015 at 7:11:33 AM UTC-5, Marcin Erdmann wrote:

Make sure that your css selectors are as specific as possible when you are selecting by text. So if say you're selecting paragraphs by text that live inside a div with some class when you want to do:

I am currently not using any css selectors, just the "ugly version" for all of my calls. By.id(), By.name() or By.linkText(). Those three currently cover all of my navigation needs. 

Ok, so you are doing it the WebDriver way and no possible inefficiencies introduced by Geb should affect you.

 

 

I think that you can simplify this to:

birthDate { $(browser.driver.findElement(By.id('birthDate')))

I will try that and report back. I had the extra factory call in there as I though I would be better of returning a geb Navigator rather than a Selenium WebElement .

You will be returning a Navigator with the code I provided due to wrapping the result of findElement() with a $() call.

After thinking about it, your solution using the ugly selectors will essentially eliminate most if not all of the wire protocol calls that would be removed by fixing #306. There might be some that will be missed but in general I think that you're pretty close to the floor performance-wise.

 

It is very interesting that selecting using By.id("id") has different performance than selecting using By.css("#id"). I suspect that it might actually be specific to IE driver (which in general is way slower than other drivers). After #333 is implemented using $(id: "id") will be equivalent to using By.id("id"). In general, the support for using By for selecting was introduced to support selecting using xpath expressions if you really need/want to. I consider using By selectors with Geb not idiomatic so we will have to make sure that you can use the idiomatic way of selecting elements with Geb and not pay any performance penalty by doing so.

To be clear I never tried the By.css("#id") version. I simply went with what seemed to be the brutal "direct to the browser ugly version".

Yeah, but you used $("#id") before using By.id() didn't you?

 

 

As long as your page is not dynamic and you're not using waitFor() {} or the "wait" content template option (or are you?) then waiting configuration will not affect you at all.

The pages are not dynamic. The only waitFor I have is on the 'at' statement ... which seems to make sense ... and having it there did not seem to make a timing difference and "you have to wait for the page to stabilize" seemed to make sense. Note that in the home grown framework we need to add a wait statement ... it is simply a "pause for xxx milliseconds" with no short circuit if the page actually is stabilized or any other tests ... before we can use a new page. 

Fair enough.

 

All content has (cache: true, required: false) on them. The required: false made a slight improvement as the contents of the page is "validated" ... or not validated as the case may be ... when it appears in the browser. It made a second or two difference.

That's surprising to be honest. The only thing that required: true means is that there is a check if the list of WebElements contained within the returned navigator is not empty. That should be fast.

 

The internal framework does not validate the page, simply fails if it can not find the attribute when it is referenced, so I wanted to make it an 'unsafe apples to unsafe apples' comparison. There is no documented coupling between cache and required ... i.e. if it's not required then is it still cached the first time it is used or is it not cached because the page is not scanned for required elements or ...? so I'm not sure if the cache:true has any effect or not. It does not appear to change the timing but cache: true does exhibit some instability that I had previously mentioned so the hypothesis is that "it does something'.

There is no change to the semantics of cache: true based on the value of required.

Btw, you should really check how long it's going to run these tests with something different than IE. I know that you have to use IE, but still. 

[Brian Kotek]

Arvid, 

While I'm all for performance, I'm still not really getting why the difference between 14 seconds and 20 seconds is such a concern? Even if you have so many tests that Geb takes an HOUR to run them, that would mean your alternative framework would finish in around 45 minutes. 

I understand that ideally it wouldn't take the extra 15 minutes...but does that difference really matter in any meaningful way? 

Again, I'm not trying to dissuade you or Marcin from trying to speed things up as much as you can. But would this sort of difference actually cause you to reject Geb, especially given all of its advantages?

--

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 post to this group, send email to geb-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/geb-user/CA%2B52dQQvxhfv%2BJZvdc_CPyd6mcVMpqLLk%3Dyzk7CSHk-q%3DmZgWw%40mail.gmail.com.

[Arvid Jedlicka]

Response to small rant ... because the "Large Faceless Corporation" Security Policy blocks easy access to the the snapshot repository. I managed to get to it and download the jars and them get them on to my machine and into my local repository but it was not easy. I consider it lucky that the In House Sanctioned repository at least mirrors most of repo1.

"LFC" is not a software development company so the thought that the 1000 person in house development staff might have significantly different access needs than the 50,000 business users never seems to occur to them because they want to ensure that everyone is safe and secure.

On occasion the term "We're so secure we can't actually get anything done" applies ;-}

[eddy bongo]

To be honest,  I think this has nothing to do with Geb. As far as I know there were no claims from this fantastic framework about such performance metrics. Whilst it is good that frameworks are optimised,  there will always be some cost that comes with it.
This seems to me like the case of a guy buying a Bentley and asking how much it would cost him to fill the petrol tank.
If there are improvements that can be made,  lets raise tickets for them and even offer to contribute where we can.

I speak for myself and this is my opinion.

Kind Regards,
Ed.

--
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 post to this group, send email to geb-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/geb-user/c07a9993-158e-47e1-bb74-85e4282d71d0%40googlegroups.com.

[Arvid Jedlicka]

Brian,

My only response ... rational or not ... is "The person I report to and who will make the ultimate decision thinks it is." ... which was enough to provide me with incentive ;-}

Yes, we've had the "do the math, here are the other benefits" discussion but there is a group that is pushing the home grown solution. They wrote parts of it earlier in the project and want to continue down that road. They have the speed so they have been focusing on making the interface less obtuse. They admit they will never reach Geb levels of syntax and semantics but I have to admit Geb will never reach their speed levels. So my goal is to get as close as possible to their performance without loosing the "you can read the test" advantage.

Sorry,

Arvid

[Marcin Erdmann]

Brian,

25% difference is significant and we should definitely do everything we can to speed it up. And there are things in the pipeline that should make things significantly better.

I sped up a relatively big test suite of Geb tests by 50% once but that was mainly due to getting rid of inefficient waiting, sleeps and other ridiculous things. The difference for the developers was massive, especially when you have to wait for multiple queued runs on the CI - the quicker you get results of your tests the quicker you can react to any failures and the process feels much smoother.

So I totally understand where Arvid is coming from. And if other devs on his team are happy with their homegrown solution then there is nothing worse one can do than forcing a tool on them that they don't see as beneficial. Maybe Geb is not for them.

To view this discussion on the web visit https://groups.google.com/d/msgid/geb-user/CAB06vMA%3DEo%3DM-1NqsustU0iks7rUWnFaLU6adZHuk3_wov0U0Q%40mail.gmail.com.

[Marcin Erdmann]

Arvid,

Sorry, I forgot that some people have to deal with silly corporate policies.  "We're so secure we can't actually get anything done" is sometimes so painfully true. ;)

All I can suggest is to do what Maven does for you but manually - look at poms of geb-core and anything it depends on and resolve all transitive dependencies manually. By the looks of it you'll just need to put snapshots of geb-waiting and geb-implicit-assertions onto your classpath manually.

--
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 post to this group, send email to geb-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/geb-user/c07a9993-158e-47e1-bb74-85e4282d71d0%40googlegroups.com.

[Arvid Jedlicka]

I just thought I would provide a follow-up.

The team decided that Geb functionality was worth the performance hit so we've adopted Geb.

The best performance\readability compromise I was able to get was by having the code generator use Selenium By.xxx statements, primarily By.cssSelector and By.name.

xxxxxx(cached: true, required: false) { $(browser.driver.findElement(By.name('xxxxxx'))) }

Regretfully performance is still a 35% hit and the previous comment ... "Be aware that the way you're accessing browser is not part of the public api so this might break in future releases." has us concerned but "we have been warned".

Thanks,

Arvid

[Marcin Erdmann]

That's great news, I hope you will not regret it.

WRT to using a non-public API, at the moment there is no plan to change it and hopefully when the next version of Geb is released the navigator creation performance issue will be resolved and you won't need to use private api and such tricks nor use By selectors to get the best performance.

--
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 post to this group, send email to geb-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/geb-user/14d06bf0-9071-4507-9301-7c841b987432%40googlegroups.com.

[Marcin Erdmann]

Arvid,

Just a follow up on this one - fixes for #306, #280 and #333 have made it into master and a release is imminent (hopefully there will be one this or the next week) so you should not need to use all these ugly selectors anymore and not suffer any performance penalty by doing so when the next version of Geb is available.

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 post to this group, send email to geb-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/geb-user/0cda852b-7d7a-4a8c-a1f0-8b30bb29a582%40googlegroups.com.

[robert eaglestone]

I've been thinking about writing a script that does something like that.  What's the general flow of your tool, and what pitfalls did you encounter when writing it? I assume you can't share the source; therefore, how much info can you give me to help prime the pump?