Whilst interviewing for jobs the topic of testing often comes up, in most of my roles I have advocated testing and even introduced it. To the interviewers surprise, some of my personal projects have testing suites. Personal projects are often things you do for fun, a way to learn/express creativity. For many, testing is not interesting. I will admit it is sometimes can be tedious.

So why do I write tests for my side projects? My personal projects by definition are things I do outside of my working hours. It is something that I enjoy, so when I get home it is something I like to do. As there can often be days/weeks/months between times when I pickup the project, a lot of the context of the project is forgotten. This can lead to me adding a new feature but inadvertently breaking something else (without knowing). For example I refactored some code which then caused a problem with a trailing newline. Even on a good day this is a risk however the gaps in time between picking up tools seem to exacerbate it. Getting home from work I am tired and don’t want to be chasing down regression, so I write automated tests.

The way I look at it, if I get to choose between:

  1. Wasting 5 hours on chasing down some bug I accidentally caused
  2. Spend 5 hours on writing some tests
  3. Just ignore it

I don’t know about you, but I would much rather the second option.

Although some of my projects have close to 100% code coverage and thorough E2E tests, I think for most cases this is probably overkill. There is a balance that should be maintained, ensure you are testing enough to be useful but not testing too much to take up too much time. So what should you test?

I think at a bare minimum, unit tests should be written around things that will be change. So if you plan to refactor or change some code, write tests around the function then introduce the changes. In the case of refactoring this gives you a base to work from, so at a minimum the new function does exactly the same thing as the original code (bugs and all). Then you can change the tests to match what you the actual expected output is, reducing the chances of inadvertently breaking something that was once working.

If E2E testing is appropriate, having it written around core functionality and some happy paths is a good idea. This means if you make changes, at a minimum the core functionality remains the same. After these I would suggest some unhappy paths.

So for me testing in personal projects despite seeming somewhat counter intuitive, is a way to reduce the amount of time I spend testing. I want to maximise the amount of creative work I do and minimise the amount of bug chasing and regression I create. This is even more important in the case of other people also using your project.