Testing Is Good, Actually

After a mere ten years of writing code professionally, I have finally attempted to start a project by writing out tests for its core functionality first. Apparently this is a whole thing. Who knew?

I tend to fall into the Grug school of thought on testing. A lot of the time I don't think it's super worthwhile to start writing tests before I really understand the problem space of a project, especially since historically I've switched frameworks and tools so often that the first few weeks of work on something is just me figuring out how the system I'm working with wants me to solve a problem.

The downside of this is that often tests become an afterthought: either I don't write them at all, or I have a piecemeal test suite that misses a lot of edge cases.

The thing I am coming to realize is that, while a lot of what's called "business logic" (complex, thorny problems with things like how data flows that I usually have to rewrite a few times) doesn't lend itself to starting out with tests, if you're making a website, which is 90% of the projects I work on, there are some pretty clear needs that it's worthwhile to start out by writing tests for. I want the homepage to be visible. I want to make sure the login form submits correctly. I want to make sure there are legible error messages when things fail. There are plenty of simple things an application should do that you probably know about before you make it.

These are boring and tedious to write, and it's not something I'm well-practiced at doing, but it's really helpful in the dev process: if you have tests that clearly define your use cases, it makes it easier to write the code and not end up missing some core functionality that you forgot to add because you were so caught up in business logic. It's basically encoding the core needs of an application into it before you make it, so you're not relying on an external design document or your deeply unreliable brain. It's also a useful exercise in plotting out an application before you start writing it.

None of this is news, obviously, and I'm sure plenty of my dev friends are horrified that I'm just starting to do this now, but when most of your work history is freelance or in code cowboy environments, it's easy to fall into the habit of not testing well. I'm pleasantly surprised to find how useful this is, and I apologize to all the TDD heads I may have offended in the past: I see the error of my ways, and I look forward to not causing myself so many headaches by not testing in the future. I still think writing premature tests is a mistake, but the stuff you already know needs to be there is worth writing as soon as possible.