Testing Your Code

I’ll own that I don’t always have great tests for my code. I just finished a hobby project where I’ve got 200 lines of code, but no tests (it’s got a README though, that’s gotta count for something, right?). “Make sure you’ve got tests for your code” is of those maxims that we all say, and there are entire software development processes which are built on a foundation of tests. That’s great; but sometimes (and especially if you or the project are new to the context) it’s hard to live up to those standards and expectations.

That’s especially true here because there’s such a variety of ways you can “write tests.” For example, “testing” could mean:

  • Running full suite of unit and integration tests, which first test the different components and then test that the components work together in the way you’d expect
  • Running full suite of unit tests on a CI/CD platform with every commit (using a tool like GitLab’s runners, GitHub’s actions, or something specific like Jenkins)
  • Having set of unit tests you can manually trigger (with a framework like pytest)
  • Having code you’ve structured that documents all of the ways your code can fail
  • Dealing with spaghetti code you wrote and are running in a notebook that runs cleanly from top-to-bottom
  • Dealing with spaghetti code you wrote, but have to tweak every run
  • Creating filtered outputs (including summary/descriptive statistics) that you eyeball after running the code
  • Creating unfiltered outputs that you eyeballing after running the code

I’ve intentionally ordered these from more mature to more “hacked together.” And that’s how they tend to get treated in terms of “value”.

I’ve come to the realization that writing good tests isn’t an all-or-nothing proposition. And, treating it as such is actually harmful in terms of making progress as a developer. Instead of an “all or nothing” approach, I think it’s better to take the perspective that “anything is better than nothing.”

That viewpoint frees you to think not about whether your tests are “good” or “bad”, and instead focus on getting on the testing ladder. Anything is better than nothing, and the more you have, the easier it is to refactor what you’ve got to make it more sophisticated (if that serves your needs). Each time you invest the time in testing, you refine how and what you need from your project, and that then makes it easier

Even if all you’ve got is a for loop that runs a series of test conditions and prints a message when there’s a problem, it means you’re not copying and pasting. And that means you don’t have hold in context “did I run all of those tests?” That’s a win in my book.