If you’ve used selenium, watir or some other web automation framework you’re probably familiar with the record and playback style of test automation:
- type this
- click that
- verify something
It isn’t very context aware, and you can get lost in the details. You practically have to execute it (or read the comments) to find out where you are.
Page-based testing is a term I made up (I’m sure I’m not the first to use it) to describe a way of organizing automated tests, that groups components into pages, so you get a little more information, and can do a bit more context validation. Essentially, you create a bunch of objects that represent the pages on a web site and group elements and actions under them. Pages can inherit common functionality from a base class, and attributes from a site. So you have a bit more descriptive code such as this:
- type ‘bob’ on mysite.loginpage.username
- click on mysite.loginpage.submit
- verify mysite.homepage.title is “Welcome home, Robert”
However, as any good tester can see, this is more work. On the one hand, it’s great because you can point to how many lines of code you had to write, and thus couldn’t possibly have time to check every possible exception case. On the other hand, it means more typing.
But with the proper level of abstraction, and some helpers to make generating the code easier. Unfortunately, it might also make improving coverage easier, but thankfully through automation.