Since the Summits, there has been some interest in the test framework I keep flogging on this blog, and rightfully so, imnsho!
They say that no plan survives first contact with reality, and the same is true for those who have started to use the framework. It is amazing how much abstraction goes on in a human brain when we learn about something, and how much that shapes how we try to approach using it.
Long story short: I have added two tests that should help with more complex scenarios, such as visitor interaction, and SPAs. The two take the idea of the
This post shall describe this and the two other tests in a bit more detail.
boolean value, i.e.
false, and the test will pass on the former and fail on the latter.
The example I use in the documentation on github is extremely simple:
Not surprisingly, this test would work every time.
On the test site I made for the labs, I use a slightly more complex test:
This test loads my test page, sets the number of books to buy to 3, clicks the “Add to Cart” button, then checks whether the data layer reflects the action, quantity and price.
When I built this test, I presumed it would mainly be used as a temporary, stop gap kind of test, meaning that if someone used it, they’d eventually create a proper test instead.
In my case the test would have been called something like
setQuantityThenAddToCartAndVerifyDataLayerElementValuesDelayed and have 4 parameters.
What do you mean, that’s just silly?
Ok, maybe it is.
Turns out that the
As an example:
The first script sets
window.aaa = true, then the test waits 1 second, then the second script returns the value of
window.aaa (which is
true, of course). This test, too, will always succeed.
I went one step further.
First, I have to apologise for the name of this one, but hey.
The test can take an arbitrary number of scripts, a verification script, plus a delay. Like
Here’s the example:
So, this test allows you to drive some pretty complex scenarios, including a check out funnel, or even testing aspects of an SPA.
I’m sure there are limitations, there always are.
But this framework is alive, it grows, and it hopefully becomes more useful each time something is added.
Next stop: the ability to stop the actual tracking requests. For that I need a built-in proxy, and that beast is still putting up quite a fight. Stay tuned.
2 thoughts on “More tests, more fun”