Testing or something

As someone who has worked mostly on small startups right when they were starting, one thing that has been commonplace in my career has been doing senior-level work with a junior-level understanding and nobody to learn from, so I've had to learn a lot from just reading stuff on the internet and tinkering by myself. One of the hardest topics to learn for me has been testing, thanks to a combination of my university not teaching anything about it, always joining projects with very little to no tests, and always having no time to stop, learn, and do them right.

All of that meant two things: I'm pretty much self taught in the realm of testing, and I didn't really have much time for it. What I've noticed it translate to is that I go for tests that are broad and test a lot of things at once, and tend to use less tooling like mocks, spies, etc. than most people. This is not a conscious decision I've ever made, but what I've gravitated towards because of those constraints: learning by myself meant using primarily what I already know, and having little time meant testing as much as possible with as little effort as I could.

Having had that experience means that what I do feels right to me, but wrong in context, because I see everybody else do things differently, and yet my way of testing has helped me immensely, way more that the kinds of tests I usually see. So I want to talk about it in the hopes of soothing my Impostor Syndrome a bit.

Unit Testing

Unit testing might be one of the most misunderstood concepts in all of software development. The point of unit testing is to test a software unit in isolation to validate its behavior independent of other units. The two critical words that get misunderstood here are unit and isolation.

A unit is usually taken to mean a function, method, or class, but what the philosophy of unit testing really understands to be a unit is anything that can be interacted with externally and exhibits the behaviors that we want to test. So if we're writing a library that exports some functions or classes, those will be perfectly valid units, but if you're writing a backend system interactable via an HTTP API, those API endpoints are your units, not whatever classes are doing the work behind them.