In addition, I've started writing failing (or empty, in the framework I'm using empty fails) tests as a todo for the next time I pick it up, so by generally keeping the tests passing I know what I was intending my next step to be when I last worked on it a week ago.
I feel there's a good universal principle underneath the advice to write tests and have good test coverage, but there are lots of situations where tests are not an option.
I'm working on a shader for a video game, any advice on how I can write some tests for it?
I'm less familiar with video games but I'm sure there's tests you could make with shaders. You could test that the shader compiles properly, you could render it to an image and compare the result, give it different parameters and see how it behaves...
This both helps keep the feature creep and complexity down, and makes sure you always have a running demo to show or play with.
Side projects should be all fun, if they are not, its not a side project its a second job.