Our team's troubles writing automated UI tests
1–10 of 28 posts
Re: Our team's troubles writing automated UI tests
#2I used to have troubles with UI tests too, but then I discovered Cypress (https://www.cypress.io/). You can still run into an issue once in a while, but it's way better than anything else and it's getting even better with each release.
Re: Our team's troubles writing automated UI tests
#3Really excited for the adaptable UI testing being done by test.ai , which solves many of the listed troubles. They use ML in 2 main ways:
1) to understand common UI flows and iconography, then automate test generation for all/many possible paths through the UI
2) to adapt the test path to UI changes or panel rearrangement
Ran into a presentation by them at the Big Data AI conference in Seattle this spring.
Re: Our team's troubles writing automated UI tests
#4I used to have troubles with UI tests too, but then I discovered Cypress ( https://www.cypress.io/ ). You can still run into an issue once in a while, but it's way better than anything else and it's getting even better with each release.
After reading through the website and watching their video, I still don't understand how it works out what it's value proposition is. Is there some demo where I can see and understand how Cypress provides value over the state of the art?
Re: Our team's troubles writing automated UI tests
#5One approach that's been appealing to me WRT to page models is to generate them from the page/component templates. It doesn't work with JSX, but it does work with other stuff like Vue or Angular templates: https://samsieber.tech/posts/2019/06/type-safe-e2e-testing-d...
My other comment is: you absolutely need data management methods if you're going to be writing UI tests. And maybe spinning up/down a testing environment on demand.
The one thing i havent fogured out (personally) is testing google integrations
Re: Our team's troubles writing automated UI tests
#6This is largely a general discussion of the problems of UI automation instead of their specific issues, as the title would suggest.
Re: Our team's troubles writing automated UI tests
#7At the project I’m currently working on we evaluated WinAppDriver (for WPF) and found it to be pretty buggy, slow and low featured. In the end we decided for a commercial product on around the same level as it, but if you’re on windows you can always use the ui automation Framework.
Re: Our team's troubles writing automated UI tests
#8I solved my UI tests by scripting a ton of screenshots for my documentation using Puppeteer, going through each thing the user can do and proving they can do it at multiple device resolutions. It was a lot of work but now it is quite simple -
await owner.click('Create plan')
await owner.screenshot('Fill out form')
Re: Our team's troubles writing automated UI tests
#9I used to have troubles with UI tests too, but then I discovered Cypress ( https://www.cypress.io/ ). You can still run into an issue once in a while, but it's way better than anything else and it's getting even better with each release.
After reading through the website and watching their video, I still don't understand how it works out what it's value proposition is. Is there some demo where I can see and understand how Cypress provides value over the state of the art?
It solves the same problem as Selenium without actually being Selenium.
The one time Selenium was reliable in my company was when our team had a dedicated, massively overprovisioned grid.
The biggest pro is it just has less random "Oh, guess that timed out?" issues than when we used Selenium.
The biggest negative is it's chrome only.
Re: Our team's troubles writing automated UI tests
#10Repurpose a graphical process automation tool. You're going to have a lot better time.