Using Geb to test ReactJS application flows vs. using Jest/Enzyme (we are a happy Geb/Spock user!!)

[Master Automator]

We currently use Geb + Spock to do end-to-end functional tests of our non-SPA (i.e. non-ReactJS or non-Angular) web applications and we are quite happy with it.

For testing ReactJS applications, I have suggested the Jest/Enzyme but there are some folks in the team who want to see if we can use Geb + Spock as the members of the team are already familiar with it.

Did any of you automate UI functional flows of a ReactJS app using Geb? If so, can you share your experiences?

Thanks,

Kiran

[Marcin Erdmann]

I’ve not automated UI flows of a ReactJS app but have on the pther hand sucessfully automated tests for a SPA using Ember.js.

The biggest issue seemed to be keeping asynchronicity under control. While not trivial at first it turned out to be totally doable as long as you keep it in mind and hide it in page and module class methods. The trick seemed to be to wrap any action that triggers an asynch action in a mathod which also contains a waitFor() call which ensures that the asynch action completes before any other action is performed.

What I’m saying is while Geb might not always be the most natural tool to use when automating flows for such applications it definitely is able to do so in a reliable manner if only used in a certain way.

I’m happy to elaborate if you would like me to and have some specific questions.

Cheers,

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/951ffd01-8e22-43d7-8002-874b00eef189%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Master Automator]

Hi Marcin,

Thanks for your response. I understand your note about using waitFor() with async calls.

The "biggest issue … keeping asynchronicity …" you mentioned, does it apply to any Selenium based framework not just Geb?

For e.g. I have seen others mention they use Selenium webdriver based tools like : WebDriverJS (http://www.webdriverjs.com/webdriverjs/) or WebDriverIO (http://webdriver.io) to test ReactJS apps.

Thanks,

Kiran

[Marcin Erdmann]

Kiran,

Yes, other selenium bindings/implementations (like WebDriverJS and WebDriverIO which from my very quick research seem to just be Selenium bindings written in javascript) based frameworks will have the same drawback with regards to asynchronicity. That is not to say that there isn’t a framework out there in the wild build on top selenium that tackles this particular problem. It will be most likely SPA framework specific and will aim at removing the need for explicit waits - an example being something that Antony Jones built for testing angular apps on top of Geb, see

https://groups.google.com/forum/m/#!msg/geb-user/XRaqUW5xkXM/CWb6_Et7AwAJ. I’d suggest googling a bit for something similar and if you find nothing like that for ReactJS you might want to have a stab at implementing something yourself based on the same principles around waiting for component renders triggered by the test to finish.

If the choice was between Geb which is familiar to your team and introducing a pure js based selenium binding I’d probably stick with Geb.

To view this discussion on the web visit https://groups.google.com/d/msgid/geb-user/734efc1b-e1de-4c82-b3ac-910deedf054a%40googlegroups.com.

[Master Automator]

Thanks for the info, Marcin. I took a look at Antony's work re: Geb + Angular and it looks great.

Also, during my survey / research I found 2 more non-Selenium frameworks for end to end testing:

•  TestCafe
• https://devexpress.github.io/testcafe/
•   CypressIO
• https://www.cypress.io/how-it-works/

I am curious what you think of these at first glance?

Cheers,

Kiran

[Master Automator]

Hi Marcin,

Can you elaborate on the cases  / scenarios of the asynchronicity-related issues dealing with React JS apps? Maybe 2 examples would be good!

Thanks,

Kiran

On Saturday, June 16, 2018 at 2:38:50 PM UTC-7, Marcin Erdmann wrote:

[Marcin Erdmann]

Kiran,

Asking me to do some legwork for you, aren’t ya? Oh well, I might as well do and learn something. :)

TestCafe seems to promise waiting for page loads and XHRs (it would be interesting to see how it achieves that) but does not seem to mention waiting for non http related asynchronicity so it won’t solve the poblem completely for you - that’s probably why it mentions „assertions that wait for page elements to appear” in the docs. I also got interested how it is able to support so many browsers and dug into it’s SauceLabs connector - it turns out that it uses wd.js under the covers making it actually a Selenium based framework.

With regards to Cypress it indeed is not based on WebDriver but is on the other hand not able to run the tests on anything different than Chrome (and derived). While I agree that cross browser testing is overrated and one should not run all their tests cross browser it’s sometimes very useful to write a test targeting a browser to check for a bug that only affects that specofic browser. Cypress seems to be doing some explicit waiting for you (as described in 

https://docs.cypress.io/guides/core-concepts/interacting-with-elements.html) but leaves it to you to ensure your tests are deterministic when asynchronicity in rendering is involved (as described in 

https://docs.cypress.io/guides/core-concepts/conditional-testing.html). My main issue with Cypress is that all the examples are low level and deal with selectors in tests (an antipattern IMHO). While they mention page objects (at 

https://docs.cypress.io/faq/questions/using-cypress-faq.html#Can-I-use-the-Page-Object-pattern) and suggest you could use them with Cypress they don’t provide any examples. Maybe it’s actually just so easy to „use regural ol’ Javascript functions” that it doesn’t warrant an example but to me it’s not obvious how to do it. Maybe it’s down to me lacking some Javascript fu, I admit it’s not one of my favourite languages.

To view this discussion on the web visit https://groups.google.com/d/msgid/geb-user/e775355c-85d3-4f53-b01d-39332195afc8%40googlegroups.com.

[Brian Kotek]

Marcin, just an idea/theory: it may be possible to inject something into a page that monkey-patches XMLHttpRequest and wraps it, to allow you to trigger logic before/after it is complete. Angular's Zone module does something similar to trigger change detection. So (again, in theory) it could be possible to replace XMLHttpRequest in the page with something that communicates back to Geb and triggers an "auto-wait" for the async call.

Unfortunately, I'm not sure even that would really work, since usually an app actually does something itself after an async call. I don't see any way for Geb to "know" how to wait for any app-specific logic that's triggered after the async call is done. I suppose as a halfway solution, Geb could just add an additional second or something onto its wait for XMLHttpRequest, which would assume that any app-specific logic would be done by then. Maybe this could even be configurable (if the user wants to make it wait longer than the default "post-XMLHttpRequest fudge factor" time that Geb sets up).

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

[Master Automator]

Hi Marcin,

Thanks for sharing your thoughts on these. And hope you have learned something! :) 

I am currently experimenting with a few "medium to heavy complexity" react web apps on the web, that deal with a lot of non-http related asynchronicity, and the best ways to "wait" for such async activity to complete during UI automation.  

One thing I like in the JS ecosystem is the async/await pattern, and the syntax is relatively intuitive to coach/train the test team which may or may not have a lot of technical expertise. I hope to share my findings soon.

Thanks,

Kiran

[Marcin Erdmann]

Kiran,

Please do share your findings. Some of them might be borrowed into Geb if it will make sense and I’m sure they will benefit other user group members as well.

To view this discussion on the web visit https://groups.google.com/d/msgid/geb-user/a1691887-8cc3-41b2-9551-7e927e827b1b%40googlegroups.com.

[Master Automator]

Sure, will do.