Test Pages, Not Workflows: Part the Second

A few weeks ago, I posted Test Pages, Not Workflows. Since then, I’ve been doing just that, with much success.

My page, I can say without revealing anything proprietary, is the application’s Users page, for which I’m adding eight page-specific tests:

  1. Evaluate page initial state:
    • Page has correct menu bar and footer elements.
    • Expected buttons are present and have correct enabled/disabled state.
    • User list (table) is present.
    • User list has correct column headers.
  2. Add users in UI.
  3. Add users from CSV file.
  4. Add users from spreadsheet.
  5. Send email to selected users.
  6. Search users.
  7. Sort users by column.
  8. Remove selected users.

These tests perform several hundred verifications, which covers the page and its operation completely.

Can you spell D-R-Y? With these tests in hand, no other test will ever have to verify anything on this page.

Now on to the next page!

Advertisements

One thought on “Test Pages, Not Workflows: Part the Second

  1. Excellent concept, efficient run-time-wise but also in terms of developer/tester focus. I liked how you addressed the major concern that each test would not be independent. And then specifically your C# implementation of that idea.
    I’ve just started looking at your blog but already I have found your ideas on CUIT very much on target. It’s great to see DRY applied to test.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s