When I last left off on Sunday I expressed my intention to add a few more tests to the ones I had already done. Unfortunately, that would likely have taken beyond today to land so I will write my 0.4 release as what I have landed in the tree now.
For 0.4 I chose for myself, the task of writing unit tests based on the tests that we had written in the spec. It took a bit of time to find a “proper” way to write the tests, however after punching out my initial tests and getting some feedback, I ended up with a few serviceable templates to build tests on in the week after. I expect that a few more iterations of reviewing will need to be done on them before a gold standard testing template can be created, however it provided a suitable base upon which I could start turning the process of writing my Cue ID tests from a voyage of discovery into an almost mechanical assembly exercise.
Probably the only major issue of note that happened during the assembly exercise was that a major parser refactor was added before my cue id tests were reviewed and pulled into the tree, causing a few small issues with my previous tests and the make file that was used to make them. The first was that the pull requester had decided to put all the tests I (and another) created into a separate new file without deleting the old files they had been copied from (without any input the creators). This meant that there were a few orphaned files left in the tree which were no longer being run through the tester. In the end it was decided to delete the files for now, but it is unfortunate that the history of their creation is now lost. The other issue that arose from the refactor was that I had to rebase my commit on top of the refactor changes. This refactor was mostly trivial as the only file that had a conflict was the makefile.am in the unit test directory. Unfortunately, while I did the conflict I did not notice that the rebase had unexpectedly created copies of the cue id variables I had added to the makefile to wire the cue id tests into the parser. This led to a few warnings being added to the pull request that I did not notice during the Travis build log. Fortunately this was caught fairly quickly after the pull request had landed.
Moving forward from today, I hope to eventually complete the other tests I was working on as they test other untested things that may have some value to confirm as functional. Overall however I think 0.4 has gone a lot smoother for me than 0.3 did and as the last numbered iteration I will be working on with this class (I am not taking OSD700 next semester due to Co-op), I believe it has been a great and informative experience working on a real-life open source project and I hope to continue contributing to it in the future.