In the last couple of days, I started working on testing my blocking implementation more thoroughly by writing a testing module called BlockTests. I decided to just use the unittest module rather than py.test (which Presley suggested), since it seemed easy enough to use and is already built in. My test module creates an instance of each of my current sample surveys (I only have 3 right now, one of which is just a dummy survey with no meaningful content), then runs a unit test called TestBlockNumber which recursively counts the number of blocks and subblocks in the surveys, asserting that there are as many as there should be. To aid with this, I created a new function in the Block class to return a list of the block’s subblocks, if it contains any, and corrected some small errors I noticed in the class.

My next objective was to test that the addition and removal of blocks using each of the available functions worked properly, but I am currently rethinking some of these functions and the structure of the survey. Currently, the user can remove a block either by its index in the survey (if it is a top level block) or by its block id. Since the block ids generated by my representation are hard to keep track of and don’t really convey the survey structure at all, I thought it would be easier to just pass the reference to the block object as an argument, rather than the block’s id. Alternatively, Emma suggested that a block could have a reference to its parent (in the case of a top-level block, the survey, or for a subblock, its parent block), and that a remove function could be defined in the block itself to remove itself from its parent’s block or content list. This seems like the best course of action in terms of simplicity for the user, but I’m going to need to rewrite /rethink the way I currently have things set up.

Once I refactor and verify that my blocking is working correctly, (as well as the other components of my survey) I will probably start addressing branching validation more thoroughly. In addition, in previous meetings, we discussed implementing exchangeable blocks in such a way that the underlying JSON representation is not altered (e.g. no new columns are needed). However, this is not a priority right now, at least not until I verify that everything else is working. Another task that would be useful to address at some point is to create doc strings for each of the objects/methods, but obviously having the survey representation implemented and tested is more pressing right now.