With Release 0.3 set for November 15, there are a number of things that need to come together. One major concern for 0.3 is to integrate all of the WebVTT C parsers that a number of people were developing separately. Even with the mentality of planning to throw one away, thankfully the development of the C parsers went different ways. But even though most bases were covered, there’s still a lot of work to do before we have a fully functioning parser to use.
And while the parser moves to 100% functionality, unit tests must be ready to test the parser for proper usage and bugs. At the moment, we created tests that validate the structure of a .vtt file, but now we have to check that the parser produces expected output when given certain files/data to parse. We discussed the number of ways that we could approach the development of unit testing. The first idea we played with was to see how the WebKit developers achieved this goal; apparently, what they did was output a text file from the parser and compare it to the expected output. It’s not exactly an “innovative” or complicated method to implement, as our teacher mentioned, and goes to show that even though we aren’t professionals ourselves, we could have accomplished the same thing.
After some preliminary research, using QUnit and node-ffi on Travis CI appears to be possible. It will be my task to ensure that building the parser and running the unit tests can be automated with Travis CI. It looks like I will also have to drive the unit tests a little, as there are a number of tests to write, and it will be much easier for everyone if the tests can be automated every time there is a change with the parser.