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.
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
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.
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!
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!