TDD – Testing Data Elements and Page Load Rules – part II

Very unlike me, I’m posting the next part just the next day. Call it excitement.


tl;dr: I describe a (rudimentary) tool that can be integrated into automated Maven tests. The tool tests that all data needed for tracking as well as the basic triggers on page load are still working fine. Put it into your build, CI, or deploy mechanism; make your web analysts and marketers happy.

The idea behind this tool is to crawl an existing list of URLs (your site, for example), record the values of all Data Elements and which Page Load Rules fire on the pages. The result is a JSON file which your friendly marketer can tailor. You then use the JSON file in an automated test whenever you want, making sure you don’t pull the ground from under her feet when you make changes.

Technical stuff

The tool is really three tools:

  1. A crawler that builds the JSON file
  2. A single-page “web app” that allows your marketer to adapt the file
  3. A test that works through the file and checks everything against the live site

I built this tool using my less than adequate knowledge of development and/or testing (I went with what people told me was hip). The tests can be run in eclipse or using Maven. They use Selenium WebDriver to actually test pages, with the PhantomJSDriver to “render” the pages. I tried ChromeDriver, too.

I’d like to amend the tool to use Selenium RC, so it could test on different browsers and OS, but that can wait.

So, here is how it all works:

I presume you have installed Maven, git, selenium, ChromeDriver, phantomjs, … the usual suspects.


Start by pulling the CatalogWebsiteDataElementsAndRulesFired project from github.

Open the urls_all_pages.txt file and replace the existing URLs with those you want to crawl, one URL per line.

Now launch

The tool will open up a browser and load all the pages you specified in the file above. On each page, it will read which Data Elements have which values, and it will browse the DTM Logger for Rules that fired and record those as well.

As a result, you get a JSON file named pageInfo.json.

JSON output after crawl
The file also contains lists of all PLRs and DEs at the end.

DEs & PLRs in crawl JSON output
This file is essentially a snapshot of what DTM does on your pages right now. It is an ideal blue print for future tests, insofar as some of what it does should not change.

The blue print is pretty raw, though. We need to shape it a little bit.


Go pull testJSONEdit from github.

This is just a web page, so open it in your browser (read “Chrome”).

The (ugly) first screen asks you to select a file.

Editor – choose a file
Take the pageInfo.json file that the previous chapter created, then press “Load”.

The page will magically transform into a matrix.

Matrix view in editor
Down the left hand side, you can see the titles of all the pages you crawled earlier. Right next to them are check boxes, one per page.

Pages with check boxes in editor
The check boxes next to the page title allow you to switch testing for a page on or off.

Across the top, you can see columns named after your Data Elements and Page Load Rules (you might have to scroll to the right quite a bit…)

Underneath the names are buttons, which I’ll explain later.

DEs and buttons in editor
The actual table has two parts:

  1. Cells for Data Element tests on the left
  2. Cells for Page Load Rule tests on the (far) right

For the Data Elements, each cell allows you to switch the test for the specific Data Element and page on or off.

Check boxes for DEs in editor
In the screenshot, I see that on the home page, I do want to test the “Page Type” Data Element (it should be “default”), but I do not want to test “Content Age in Days”.

The “All on” & “All off” buttons at the top do exactly what you’d expect: they switch testing for the Data Element on or off for all pages.

Similar for the PLRs: you can switch testing them on or off for each page.

Check boxes for PLRs in editor
The “Normal Page Load” rule fires on all the pages here, whereas the “Blog Article Extras” rule does not.

An again, the “All on” & “All off” buttons do what they say.

When you have finished checking or unchecking the appropriate boxes, you can click the “Show JSON” button at the top left corner.

The matrix will disappear, and you’ll see the JSON representing the test setup.

JSON in editor
The next step is to copy the generated JSON.

Just click into the field marked with the red arrow in the screenshot, then press CTRL-C or Cmd C to copy the JSON and paste it into an editor.

Save it somewhere. You’ll need it in the next step!


Pull TestDEsAndPLRSOnSite from github, then copy the file you generated into the root folder of the project.

You are now ready to run your first test!

Project directory for test
You can run the test in eclipse, if you want, or you can run it using Maven. Since the latter can be automated, I’ll do that.

mvn clean test -Dtest.description.file=testdescription.json

The test will run some time, depending on how many pages you told it to test.

The way it is currently made, it opens a new browser for each page. I did it that way because I would potentially like to run the tests in parallel. As far as I understand Selenium Grid, that should be possible, but not with my current, single, monolithic test.

There is much still to do! Which I think is great!

2 thoughts on “TDD – Testing Data Elements and Page Load Rules – part II

Leave a Reply

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

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

Facebook photo

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

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.