Every time I hear about record and playback UI automation, that conversation is accompanied by some trope about how it isn’t automation, or how it isn’t maintainable, or how it is somehow less useful. I’ve been using these tools for years now and find them to be none of those things when used in the right contexts.
Coded solutions like WebDriver escape these problems by using the Page Object pattern to abstract away all the scary bits. I do something similar with record and playback tools.
The first question for me is, how do I want to organize my tests? Page Object does that using pages in your software. For example, user administration will have a class, the login page will have a class, the shopping cart will have a class, and so on. I try to get as close to that convention as possible.
Record and playback tools run code, just like every other testing solution, but it is all hidden away. Instead, what we see is folders, lists of steps, and occasional small bits of code. Rather than having a separate folder structure for utilities, I like to keep them in the same folders as the tests that will reference them. Some tests will cross multiple pages, but if the focus is on a particular page, I stick it in the folder for that page.
So you have a folder in your tool for a page and you want to build some tests for that page. You also want those tests to be as short, useful, consistent, and easy to maintain as possible. I get there with programming principles, primarily through DRY, or “don’t repeat yourself.”
If there is a series of steps that I will need to use more than twice, I abstract those out. Let’s say I have a folder for tests designed around a user administration page. Before I think about the testing problems on the page, I know there are two things I am going to do a lot of: navigate to the user admin page, and wait for the page to refresh after a save has occurred. I will immediately create those two utilities to be used in my tests.
The navigate utility handles navigating to the page and looks at a couple of elements that need to be on the page for it to be useful. Once the navigation step has run, I am ready to interact with the page however I need to. The save utility uses the same pattern. Click save, verify I am at the right URL, and verify that the right elements are on the page.
Record and playback shouldn’t be a nightmare to deal with. While these tools generally aren’t dealing in code, so I can’t use a lot of the patterns designed for programming libraries, I can fake them enough to be useful. One key for useful UI automation in any tool is abstracting at the right level.
