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.
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.
2 comments
[ 0.16 ms ] story [ 16.2 ms ] threadGoal 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...