Reading Time 3 minutes
Writing E2E UI tests when UI is not ready is not an easy problem to solve. Ill get right to the point, it is tough writing a UI driven test for an application before the UI is ready. When a new application is in development, the first types of tests written are unit tests. However, trying to write a UI driven test can be difficult. How do you write an E2E test for an application where the UI, functionality and requirements may change every time new code is committed? Well, allow me to tell you how I approached this problem.
E2E UI Tests for New Applications – Let’s Understand the Problem
Let’s imagine for a second that you are just about to start a new project for which there is no UI, no backend, no tests, nothing. Simply said, you are currently in the planning stage of the project. You are then tasked with writing Acceptance Tests for the project. In the absence of any UI, how do you write any UI driven tests?
Or how about the situation where the UI is mature. However, the functionality for which you have been asked to write a test for does not exist yet. Again, in both this and the previous instance, how do you approach writing UI driven tests?
Should We Just Wait?
One approach I had considered was to simply wait until the UI was ready. This felt like the perfect solution to a problem which I as an Automation QA had no real control over. Overtime I had then noticed that this was not a sensible solution on the grounds that if the functionality changed then there was no test to capture it. Naturally, a change in priorities in an Agile environment also meant that writing the UI test just got pushed back sine the requirements were delivered.
After considering the ‘wait until the UI is ready’ method, it turns out that ideally I should have either written a failing Acceptance Test (used TDD) or written the test right after the functinality was delivered.
In hindsight it looked like waiting did not seem like the right solution.
What Can We Do Then?
So, if waiting did not seem like the right solution nor was it possible to write a passing test for the UI in parallel to the development – how could I approach and resolve the issue?
At the time the solution did not seem obvious to me, I figured out that the solution was to actually write a failing test!
Writing failing E2E UI tests meant that the requirement was captured and documented in the form of a test. It was then running as part of the CI build and therefore serving as a warning. I decided not to fail the build as a result but instead serve as a warning. Once the actual implementation was complete, the test started to pass. Once the test started to pass, I removed the warning on the test and instead started to fail the build in the event the test failed.
And that was it.