Isolating and extracting test content in large-scale Drupal implementations

I've worked on a number of large-scale Drupal implementations involving lots of content types, large testing teams, and many thousands of nodes generated as a result of content migration.

Dave Leonard
#Drupal | Posted

I've worked on a number of large-scale Drupal implementations involving lots of content types, large testing teams, and many thousands of nodes generated as a result of content migration.

For these reasons, many times it can be difficult to isolate and extract test content (particularly when you are testing out semantic tagging functionality such as Open Calais and you want to simulate what Open Calais will extract from your content using realistic test content). It's not as easy as just filtering based on date created (if you're doing regression testing test content will be coming in all the time) or who created the content (when you are distributing the testing amongst a large team on the client side this becomes ineffective).

Another problem: placeholder pages are sometimes put in place so that navigation menus can be established and users can begin clicking around. These placeholder pages are "real" content, but they need to be revisited and massaged by authors before the site launches so that they look professional.

We have found that an effective way to mitigate all of these issues is to put a simple process in place that works as follows:

Create a "Content Status" vocabulary and make sure it is applied to all node types

This needs to happen as early as possible in development - which means you'll need to remember to enable this vocabulary for any content types that subsequently get created.

Make sure that this vocabulary is single-select and required (which forces users to select one of these terms when creating a content item/node).

Populate the "Content Status" vocabulary with terms

Here is a typical set of terms I've used in the past:

  • Test Content
  • Needs Editing
  • Ready for Launch

Considerations when content migration is involved

If content migration work is being performed, make sure that the Content Status is being set to Test Content for all of the imported nodes during initial imports...you may even want a separate term for this like "Migrated Content".

Flag test users (particularly when importing large lists of users/subscribers from an existing site)

Implement a role that doesn't have any permissions associated with it called "Test User", and apply it to users you create during testing when you are testing out the user experience associated with each user role.

This approach isn't quite as bulletproof because there is no safeguard requiring you to grant users this role, your team will just need to be diligent about it.

Use the Content and User lists to filter out and extract test content

Once you've isolated your test content and users as described above, you can use the Content lists and User lists in Drupal core to quickly extract all of your test content.

This methodology for isolating and extracting test content in essential in order to avoid launching a site with pages full of lorem ipsum (or a photo gallery from your dog's 5th birthday party).

Dave Leonard