Testing to destruction

By Serdar Yegulalp | 2016/07/06 08:00

I wrote before that because MeTal is so protean, right now it doesn't make sense for me to devise a test suite. I'd rather wait until the APIs and internal mechanisms aren't a constant moving target before attempting to do that. In lieu of actual test-driven development, though, I have some manner of testing, which could be colloquially described as "break all the things".

Attempting to move my own blogs to MeTal was a big part of this. There are so many oddities, edge cases, corner cases, and unforeseen problems inherent in such a job -- but it's a great way to tease those things out, debug them, and also do something about the bad assumptions that gave rise to them in the first place.

For instance, the other night I found that the copyright information tags for images weren't being moved over when I ran the import script. Fixing that bug forced me to rethink how key-value information could be associated with objects, and I came up with some mechanisms for ensuring that KVs are consistent after performing low-level bulk database operations.

Because the associations between KVs and their parent objects are not strictly enforced at the database schema level, they have to be enforced in the ORM. It's easy to do that when deleting individual objects, but not so easy when performing batch delete queries. (I ended up writing a class utility function that would clean up any KVs left over after such an operation -- not the ideal solution, but I suspect most people are going to be doing individual rather than bulk deletes anyway.)

Another thing I'm going to be doing in the coming weeks is changing some internal API signatures. -- more fallout from the above. This will almost certainly break things, but that's what version control is for. And the more this stuff breaks now, when I want it to break so I can observe the breakage up close, the better. It'll mean things will be more robust later on.

comments powered by Disqus