I recently wrote a tool to manipulate images embedded in mp3 tags: id3-image. To be able to make changes to the code with confidence, I needed tests. Rust comes with the very sensible
Writetrait that could have allowed me to mock any IO (a blog post for another day), but in this case, the project relied on the excellent id3 crate, so I wasn’t doing any file-writing myself.
Instead, I wanted to have an actual mp3 file and an actual image, apply my code to them, and inspect the results. This generally isn’t difficult to do, but I ran into a few unexpected gotchas, so I’ll summarize how I ended up implementing it.
One of the more exotic features of Vim is its remote control functionality. Basically, if you invoke Vim with
--servername SOME_NAME, you’ll be able to send commands to it with another Vim instance. Using this, I’ve recently attempted to fix a common annoyance with vimscript – its limited testability. By spawning a remote instance and controlling it through ruby code, we can use cucumber to perform simple integration testing for Vim plugins.
This is not something I’d do for all code I write, but in some cases, it could be a life-saver. My splitjoin plugin is one example of a project that I wish I had a good test suite on, considering the amount of regressions I’ve had when modifying functionality. In this blog post, I’ll describe some ruby code to drive a Vim instance remotely and a few sample cucumber steps you could write to make use of it.