Naming is one of the most difficult tasks of development. My last team debated names of things because communication is crucial, but it is a challenge. Naming a paradigm, pattern, principle, namespace, class, variable, or whatever is an attempt to communicate with another engineer about a broader set of related ideas using a condensed term. Computers don't care what you name things in your code; It all becomes binary once it's compiled anyway.

When I started with my last team, we mostly all knew the term unit test, but our interpretation of what that meant was certainly varied. I was used to a short Arrange of about five lines or less, a line or two to Act, and then one Assert. This team's unit tests were sometimes more than a hundred lines long and each had a laundry list of assertions. However, these classes were tested in isolation, so the term unit test still applied.

I recently stumbled upon this video at Industrial Logic where GeePaw Hill discusses their use of the term microtest:

I have been struggling for years with the various types of tests that fall under the unit test umbrella. It's nice to have a term that nicely encapsulates the kind of tests that we use for TDD and I'm prepared to use the term microtest from today forward. It's far more clear than any description I've used in the past, and if the industry can adopt the term at large, we can much more quickly distinguish the types of tests we discuss. Then we can move onto the next important discussion.

What do you think about using this term? Does it help clarify these types of tests for you?

Photo by Agence Olloweb on Unsplash