There can be a strong impulse to build automated testing (or even manual testing) around workflows. Makes sense, right? A workflow embodies the flow of actual work done by actual persons, so it’s good to test it.
The thing is, workflows are like chess games: many begin with similar opening moves. So when we execute a large number of workflow tests, many of the opening steps are repeated over and over again.
This is extremely wasteful of wall-clock time.
An alternative is to design testing that minimizes repetition.
What would that look like? Well, let’s take advantage of the page object pattern.
The page objects cover the application, right? So there’s a page object for each page in the application. Let’s organize the testing around that.
For each page, we can create a page test that:
- Navigates to the page the most efficient way.
- Performs and verifies all actions that can be initiated on the page.
- Verifies all links on the page.
Much more efficient than a workflow test, is it not?
Like any lengthy automated test, the page test needs to guard against premature termination caused by an unhandled exception. The strategy I’ve used in the past is for the test to be divided into major parts, each of which is a function. If an exception is raised, the function catches and logs it, then returns cleanly so that the next function can continue.
(In my C# code, I’ve done this not by putting a try block into each function, but instead passing each function name to a special “catcher” function, wherein the named function is then invoked inside a try block.)
I’ll be trying out the page test concept in the sprint that starts today (yes, I’m agile!), and will report back.