Several posts ago I mentioned that I was waiting to see which cloud provider would be up to hosting Project Fangorn first. In my last two posts (one, two) I talked about some of the issues with testing web apps on the GAE platform, but I didn’t mention what it was I was actually testing.
At the end of last month, I had decided to create an abstraction over the GAE datastore API so that I could continue working on Project Fangorn without worrying about potentially having to rewrite all of the code dealing with the GAE datastore to use Amazon’s SimpleDB (or something else). I also decided to design this abstraction so that it could serve as the foundation of a Python Space-Based Architecture (SBA) implementation.
At this point I’ve only done the distributed object store portion of SBA. This would have been a trivial wrapper over the GAE datastore API if it inherently supported transactions across multiple entity groups, but since it didn’t I had to provide that implementation myself. I started out just intending to do a prototype of it, but it didn’t take very long for the implementation to become to complex for stability to be maintained via a few trivial tests. Thus, I decided to tackle it using TDD with a goal of the tests being applicable to other implementations of the my space-based storage API besides the GAE one. Even if I stick with GAE, something like Durus may prove useful for my other non-web based game project that has been on hold since the end of May when I started working on stock analysis software (although I haven’t blogged about that recently, I’ve still be working on stock analysis software and will post something regarding that soon).
Now that I have a slew of tests for my space-based storage API and a working implementation for it (that has a lot of room for perf improvements but that can wait for now), it is time to move onto creating some integration tests for Project Fangorn’s game code, so I can refactor it to use my space-based storage API before I expand the game code any further.
