Use cassette-style test fixtures

[elliottwilliams]

At some point (probably when I need fixtures other than a single route/vehicle/station), I'd like to have a way to more quickly obtain a new set of test fixtures. Already I have had regressions in functionality because something changed in Shark, and my test fixtures hadn't been updated to note the change. Having easily-voidable test cassettes would seem to work well in this situation.

[elliottwilliams]

@faultyserver it'd also be helpful if there was a way to query the "version" of the Shark data model. Proper could determine whether its fixtures are out of date automatically.

[faultyserver]

I could see adding a version kwarg to all events, probably managed by a middleware.

I'll play around with some implementations today and report back.

[faultyserver]

@elliottwilliams how does that look? (The next commit adds the version kwarg to all events coming out of ObjectManager).

The other approach would be to include version as an object attribute. Would that be better?

[elliottwilliams]

Could the version kwarg be set on a system level and not on an object level? From the client's perspective, I think having to keep track of version numbers per object type is a little too granular. If this were the case, then version can be thought of as an "API version", which to me seems appropriate to pass as a WAMP kwarg.

If you'd prefer to version objects, not the API itself, then I think they should be object properties.

Another way of thinking about it is that if we version objects, then clients will be able to check for version compliance at the object deserializing stage. If we version the API, then the version compliance check can be done at the event-handling level.

[faultyserver]

.............I don't know why I didn't think of doing it at the system level. I'll switch to that some time tomorrow.