 |
Every single company I know (except our forward-looking customers, of course) is creating a testing framework.
It usually goes like this historically: first tests are simple plain Selenium, but as your team grows people tend to start extracting common code in testing frameworks.
They are supposed to help people to develop tests faster. Well, they do a little bit. But need to be updated since most of them will rely on XPath locators, and, therefore, they get out of date every time the product changes.
However, why would need to do it in the first place if you can express what needs to be tested in plain English like this: https://blog.testrigor.com/natural-language-recognition-for-software-testing/
...
click on "Add to cart"
click on "cart"
enter "San Francisco" into "City"
...
On top of it, you can define subroutine “add pants to cart” and do it like this:
add pants to cart
click on "cart"
enter "San Francisco" into "City"
...
The approach testRigor has is dramatically more stable since it relies on how people work with the page regardless of the underlying structure. That allowed our customers to compare our tests with their own Selenium test suite and they found that our testing is by far more stable up to a point where it doesn’t make sense for them to support their own code.
If you’re still writing your testing framework, then request a demo below.
