Ask HN: When do you write tests for side projects? - kyleperik
======
itamarst
Same as for any software: it depends on your goals and situation.

Goal is learning new technology: probably not worth it.

Goal is something people will pay for: do you have evidence anyone will pay
for it? If not, probably best not to start in first place, but if you insist
on continuing, you need a different form of testing, testing for viability as
a business.

Then there's questions of what kind of software it is, and where each part is
in development cycle. Stable parts need unit tests to stay stable. Unstable
parts will be rewritten so unit tests just ensure something you know will
change doesn't change, which is waste of time.

Full talk on topic here:
[https://www.youtube.com/watch?v=Vaq_e7qUA-4&feature=youtu.be...](https://www.youtube.com/watch?v=Vaq_e7qUA-4&feature=youtu.be&t=63s)

------
z3t4
I write a test for each bug I fix, so it don't show up in production again.
And when I do manual testing that get daunting eg. I have to make several
steps to reach a state. I also write an automatic test. Or when I'm not sure
something will work I make a basic "assert" test or some "defensive
programming" that checks if the state is sane during runtime. I don't do unit
testing. Most programmers get unit testing wrong, the single reason for unit
testing is to get full code coverage. So if you do unit testing you should
write tests from day one.

