We have automation scripts set to test our App measurement code that just grab the s. object and then validate that the appropriate s.props and s.evars values are set.
We are moving to the WebSDK. I'm thinking it will be faster for our dev team to update their script to pull the appropriate _satellite.getVar() rather than having them listen for the network call and parse the xdm.
What has anybody else done?
This is a good question.. We haven't moved to WebSDK yet, but we will have a similar issue when we do.
Part of the problem here is that there will be one more layer of extraction with WebSDK.. basically, while you may be able to see the values of your Satellite Variables, or what is passed in the XDM format to Adobe, there is no true way to ensure that those values are actually making it to the intended dimensions.... I don't know if there is any way to combat that...
If you check the Satellite Variables themselves (and not the XDM call), there is a potential for the Satellite Variable itself to be set with a value, but it might still be missing from the XDM call... this could lead to false validation; as this is now 2 steps removed from the final destination in Adobe...
Also, depending on your setup, is it possible that your Satellite values could be set, then updated within the execution of the page? In short, is it possible that during the loading of the page, the Satellite Var may show different values? If you do decide to check at the Satellite Var level, you would have to be careful about timing the checks to ensure that you are getting the final value (that the automated test isn't running too soon).
I don't know if there is a good solution for this yet, but that's at least my 2-cents worth on the approach..
So true. Thanks for your thoughts.
I am not as concerned about the destination changing as that is only done deliberately and we would expect to be doing manual checks anytime that we change a destination.
Our satellite variables do not change unless some action happens on the page so we should be fine there.
I saw some post a while back that suggested validating the datalayer, but that is even one more step removed from the final destination.
I hear you!
Validating the Data Layer is good, but not necessarily as part of automated testing... but if you start seeing very wrong details in your tracking, making sure the Data Layer is correct is generally the first place to check.
But if your implementation is like mine, you are probably processing the Data Layer information, and not using a lot of that info raw... so testing at that level would be too early for a lot of testing to be effective... Unless of course everything in the data layer is the final value, and the Satellite Vars are just reading the values as-is... but again, if the Satellite Var fails to read the info but the Data Layer has it, you could still get a false "pass".
In an ideal world, checking all the levels would be great... but the time and effort to write that code and keep it up to date makes that an unrealistic and not terribly feasible option....