SEM Development

Some highlights of the recent version upgrade of Google AdWords:

Local Time Zone Support
This is nice.  Now I don’t have to figure out the timezone myself.  I think it makes my code a little more portable since it’s one less thing I have to configure.  I’m not sure if it was part of this release but it looks like the ReportService uses endDay (format YYYY-MM-DD) instead of requiring the time as well in endDate (format YYYY-MM-DDTHH:MM:SS).  Now I don’t have to specify that I want the report from midnight to midnight.

Traffic Estimator
Another change in this service.  I think it highlights how hard forecasting is.  They replace avgPosition with lowerAvgPosition and upperAvgPosition.  Same goes for clickPerDay and cpc estimations.  Next step … changing the values to include insideTheBallpark and wayTheHellOff.

Zero Impression Reporting
This is fantastic.  Now I can see if Google has changed the status of any of my low traffic keywords without grabbing them all with getKeywordList.  A nice savings on my quota.  Unfortunately, it’s not active yet.

Unique Request ID
This may be good for internal auditing but not much else.  I doubt Google is going to use it as a reference number for tech support.

I’ve recently realized what a pain it is to write regression tests for modules that access the Google AdWords and Yahoo DTCXML API directly.  I already hate writing tests so this is pain^2.  Here’s my setup:

The green box is Google’s AdWords API.  The blue box is my API object that uses SOAP::Lite to access the API.  The red box is supposed to represent a Criterion object.  I’ve talked about how I create an object representation of the API services before.  Of course there are more objects but they’re not important for this discussion.

I can take two approaches when writing tests for the API object:

1. Ask for login info and do live tests on the API.
2. Write canned SOAP envelopes and insert them into my module.

I originally took the first approach which works OK but dies if the service is down, the person enters the wrong login info, an on and on.  Now, I know I could write tests that make sure the service is up, or retry a call if a 500 is returned but these are just tests.  When I have to introduce exception handling into my tests scripts they’ve ceased to be tests.  Also, it uses up Google’s quota units and gets stuck on Yahoo’s rate limits without careful planning.

I got the idea for the second approach by looking over Mike Schilli’s CPAN contributions.  Specifically, I looked at Net::Amazon which is a perl interface for the Amazon shopping API.  He’s written canned files that hold various responses that should be expected from the Amazon service.  He then tests against these files rather than the actual service.

I think I’m going to try the second way out for the bulk of my tests and then throw a few live tests in for a sanity check.  I guess I could also keep local versions of the WSDLs and then do diffs against them to make sure they haven’t changed.  The problem is that my API modules are written to change with the WSDL (or schema for Yahoo! Search Marketing).  Taking that in account, I’m not going to keep local versions of the schema or WSDL … for testing anyway.  It’s a good idea to keep local versions to save loading them over the internet every time an object is instantiated.

I’ll talk about how I test the object layer modules in a later post.