3 ms·

UI-level tests are the only kind that reliably test the full stack of your application. No amount of unis testing will catch a missing button or a wrong config

UI-level tests are the only kind that reliably test the full stack of your application. No amount of unis testing will catch a missing button or a wrong config setting. And while recorders present some challenges, manually coding UI-level tests make the maintainability issue an order of magnitude worse. The best way to make web UI tests stable is to involve engineers and make sure that the pages are structured in the way that make automation and validation easy. Usually the changes required for this are trivial. When they're not, it often points out something in the UI that doesn't make sense anyway, like having no confirmations for user actions. And in any case, automated UI tests are still better than manual UI test, which is what a lot of people are stuck with.

danidiaz 9y ago
I agree that is is important to structure the application to facilitate testing. But I find this surprising: > And while recorders present some challenges, manually coding UI-level tests make the maintainability issue an order of magnitude worse. In my experience, writing the tests manually for sufficiently "regular" applications ends up being more maitainable because you can put repeated logic in shared functions and classes, making it easier to adapt to changes in the GUI. Page Objects are an example of that: https://github.com/SeleniumHQ/selenium/wiki/PageObjects https://github.com/SeleniumHQ/selenium/wiki/PageObjects Also, writing the tests manually lets you use "explicit waits". http://elementalselenium.com/tips/47-waiting http://elementalselenium.com/tips/47-waiting Specifying exactly what we expect to happen tends to be more robust (and faster) than either using static sleeps or some kind of implicit wait. Recorders tend to have problems finding concrete things to wait for, especially for very dynamic pages. (That said, I'm not against using something like Chrome DevTools to identify elements in the page, evaluate potential selectors, and so on. That is indeed useful.)

danidiaz 9y ago

I agree that is is important to structure the application to facilitate testing. But I find this surprising: > And while recorders present some challenges, manually coding UI-level tests make the maintainability issue an order of magnitude worse. In my experience, writing the tests manually for sufficiently "regular" applications ends up being more maitainable because you can put repeated logic in shared functions and classes, making it easier to adapt to changes in the GUI. Page Objects are an example of that: https://github.com/SeleniumHQ/selenium/wiki/PageObjects https://github.com/SeleniumHQ/selenium/wiki/PageObjects Also, writing the tests manually lets you use "explicit waits". http://elementalselenium.com/tips/47-waiting http://elementalselenium.com/tips/47-waiting Specifying exactly what we expect to happen tends to be more robust (and faster) than either using static sleeps or some kind of implicit wait. Recorders tend to have problems finding concrete things to wait for, especially for very dynamic pages. (That said, I'm not against using something like Chrome DevTools to identify elements in the page, evaluate potential selectors, and so on. That is indeed useful.)