I’ve mentioned testing in one prior blog post, but now I have a nice case study of developing automated tests. Also, it’s sort of my only thing I can write about? I was on a vacation for a week and a half, y’all. In case you were wondering why the update is a little late.
(Did I actually get to the case study in this blog? No. Maybe next time.)
Why do we need tests?
First off, if you’re asking that, your code has bugs in it.1 Testing, especially Test-driven development, is a way to minimize bugs. Ideally you can take the bugs you know about (or at least think to check for) all the way down to zero. The corollary of this is that not testing is a great way to have bugs that you might’ve noticed at some point.
Good tests are completely automated. Once you’re ready for code to be tested (e.g. you finish a feature/script and want to add it to the main repository) the test should trigger and check that you haven’t broken anything which is supposed to work. With a whole team collaborating to create tests, you’re not reliant on just checking the bugs and edge cases that you would consider. Instead, you get an easy way to check all the bugs that anyone thought might pop up.
I’m assuming you would like your code to have less bugs2
What can you test?
Anything! Here are some tests that vg has:
- command-line small graph conversions/viewing
- a lack of “yeet” in the code (yes, there were yeets for a brief time)
- the
simplify()function works as expected - help-text matches underlying code for options3
- zip code trees (I’ll let Xian Chang’s thesis explain those) can handle a bunch of randomly-generated graphs
- a helper script runs without crashing
- the minimum supported compiler version actually is supported
As you can see, these don’t fit a single mold. Sometimes we call functions from within the C++ code, and sometimes we run the tool on the command line. Sometimes we decide to ban a word, and sometimes we force command line options to be formatted correctly. Sometimes we use random data, sometimes we generate specific data and expect a given result. Sometimes we even test things peripheral to the code itself, such as a helper script or its compilation.
If you want your code to be able to do something, then you need to test it.
How can you test?
Well, that’s a whole post in itself. A post I’ll probably write at some point, but still, too much for now. Look up “unit test <language>” on your favorite search engine. There are more ways than I know. In Python4 I favor pytest. On GitHub you can set up automated workflows. Can’t hurt to test it out, yeah?
- I mean, all code more complicated than the intro stuff like “Hello World” has bugs. But if you profess to have code that doesn’t need tests, then the chance of lacking bugs drops from “finding a unicorn” to negative.
- If you don’t care, then, well, I’m honestly not sure why you’re reading this blog. Why care about style if you’re fine with actual errors?
- Yes, I spent a week of my 1.5wk vacation hyper-focusing on a script for work. Yes, this included weekends. Yes, “weekends” includes the day I went to my friends’ wedding. In my defense, I enjoyed it? The coding and the wedding, I mean. Both. Yeah. That’s my story and I’m sticking with it.
- Ah, Python. I miss you. Especially dealing with C++’s… quirks, I’ll call them quirks. More polite than what I would normally say.