Thanks to the efforts of Caitlin, Rick and Humph, our unit testing suit using Google Test is (mostly) ready for consumption! While I was initially disappointed that we had to abandon our Node-FFI efforts, I’m pretty impressed with what I have seen and read about Google Test.

Initially, I was confused by the term ‘test fixture’ in the context of Google Test. When I worked with JavaScriptMVC at my coop, a test fixture was used to refer to a dummy AJAX call that would hit a .json or .xml file rather than an actual web service. This would allow client-side developers to develop without having to wait on the back-end to be complete. In the context of Google Test, a test fixture is a test class that has a set of instructions to run either before or after a test that are necessary for the test to run (example: processing a file, and then testing the results. Processing the file would be a part of the SetUp procedure).

I’m going to be converting the initial tests I wrote for Release 0.1 to this unit test format. So let’s get started on getting started!

The First Roadblock

As always, I start off by pulling the latest changes from Humph’s seneca branch, our ‘central’ repository. However, I encountered a very strange problem right off the bat. Right after I pulled the latest changes from Humph’s GitHub repo to my clean local seneca branch, my working directory seemed to be in a dirty state. When I ran a git status, I was told that a file called ‘test/spec/tc2023-longstring_with_utf-8_crlf.test’ was modified but not staged for commit. This is pretty strange, as I just pulled this file from another repo. How can it already have changes? I was getting strange warnings about CRLF characters being replaced with LF in the file in question. However, due to the file’s name, I assumed that this test was supposed to be testing CRLF line endings and that this was intentional. My git configuration currently doesn’t alter line endings do I’m not sure why Git would be telling me that it would change them. I’m still not sure what is going on but for now I’ve just created a new branch off of seneca, deleted the file in question and continued upon my merry way.

Conversions

I navigated my way into where our unit tests will live, the aplty named ‘test/unit’ directory. Because Vince, Deva and I initially worked on tests that had to do with the cue times, I made a new directory! mkdir cue-timings To be honest, I wasn’t exactly sure how to structure this directory. I noticed there were two other directories currently in the unit folder, ‘cue-settings’ and ‘payload’ so I decided to peek into those folders to see how things were being organized.

The cue-settings folder had a bunch of .vtt files in the root of it, with subdirectories containing more .vtt files. The payload folder consisted of of a samples subfolder which contained more .vtt files. I’m not sure if we ever came to an agreement in class on what our folder structure for these unit tests are going to look like. For now, I’ll keep the test fixture in the root of the cue-timing directory and maybe put specific tests in subfolders, along with their respective .vtt files.

What does my test fixture need? In my opinion, a test fixture for Cue Timings should parse the .vtt file, and create data structures to contain the different tokens that make up a cue timing. This will make it very easy for anyone to test cue timings. I don’t see a need for a destructor-like method at this point in time.

So that is what is ahead of me. We are in the final stretch of the semestser, and while I’ll be continuing this adventure in OSD700, I want to finish as much as I can before the end, so expect more blog posts detailing how I write my fixtures and tests in the days to come!