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.

Introduction

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.

Crawl

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 App.java

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.

The file also contains lists of all PLRs and DEs at the end.

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.

Adapt

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.

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

The page will magically transform into a matrix.

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.

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.

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.

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.

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.

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!

Test

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!

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!