So you want to start with UI test automation for your product but a complete overhaul of the product’s UI is already planned? Tough luck – there’s nothing for you to gain until the overhaul is completed. Or is there?
Let’s be honest: If you would dismiss your UI test automation ambitions every time the UI of your product might change you will probably never start. While small changes to the UI can be easily compensated by using some form of an object repository, the extensive UI redesigns are what really makes the job interesting (or “hard”… but that’s just what makes it interesting, isn’t it?).
My colleague Barbara Göller and I wrote an article to provide you with another approach that might help you to further decouple your tests from the UI. The approach is based on the experiences we gained and the solution we came up with while developing automated UI tests for a product that was about to go from “one input mask to rule them all” to “one input mask per workflow”. The (German) article Keine Angst vor Veränderung – Stabile automatisierte Oberflächentests trotz Redesign was published online by Informatik Aktuell.
The approach uses two layers of abstraction: An upper business layer, providing a business process-/workflow-based language for your tests to be written in. And a lower technical layer, decoupling the layout of the UI from the actual UI technology (a standard page object model).