"You’re not going to just deploy your application and forget it even exists!" well maybe you are. In fact maybe there's quite a large class of coding, which is in the form of quick experiments never to see the light of day. Maybe many proper applications start life like this (as a not-really-serious experiment) so then I guess there's a question of when to decide to get serious and start adding unit tests to this thing.
My point is, surely its forgivable to not always be unit testing from the beginning. Or am I just not buying into this properly?
I saw some interesting ponderings at the other end of the spectrum, if you're unit testing yourself up to the eyeballs (going for 100% coverage) ...maybe you're going too far: labs.ig.com/code-coverage-100-perc...
Once you make unit tests part of your routine, you will likely find that you are much more efficient at writing your quick experiments that never see the light of day - assuming that you're working in a context where you are already proficient at writing unit tests.
If your quick experiment is of the "let me see if I can integrate these two unfamiliar technologies" sort, then of course unit tests aren't going to be helpful. But if your quick experiment is (or can be) easily testable, then it most likely makes sense to write the tests.
In essence, I'm convinced that "will it go to prod" is completely orthogonal to "should I write tests." Unit tests are there to make development easier. If you want your development to be easier, make a conscious decision about whether the effort to write the tests is justified.
I regularly write tests for the small things I write as experiments, or small tools, things that I "know" will never go to production - how better to test that the experiment/tool/whatever works than with automated tests?
You often also save time by setting up some automated tests, as instead of doing some complicated manual process to test if your stuff works after making changes your unit tests just get triggered automatically (if correctly set up) and will tell you if the code works.
Additionally there is a clear benefit in writing code that is easy to test - it's often better in quality due to readability, less dependencies, less "God object" -type issues, and so on.
A *very* seasoned software engineer, I wrote my first basic game, a lunar landing game, in Basic in 1969. Currently I am doing web development in Ruby on Rails, JavaScript, Elm.
This is the most common excuse given to me for not writing tests, and then holy cow, that sucker is in production and people are looking at it daily... too late to write tests, we need more features now!!
Write the damn tests.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
"You’re not going to just deploy your application and forget it even exists!" well maybe you are. In fact maybe there's quite a large class of coding, which is in the form of quick experiments never to see the light of day. Maybe many proper applications start life like this (as a not-really-serious experiment) so then I guess there's a question of when to decide to get serious and start adding unit tests to this thing.
My point is, surely its forgivable to not always be unit testing from the beginning. Or am I just not buying into this properly?
I saw some interesting ponderings at the other end of the spectrum, if you're unit testing yourself up to the eyeballs (going for 100% coverage) ...maybe you're going too far: labs.ig.com/code-coverage-100-perc...
Once you make unit tests part of your routine, you will likely find that you are much more efficient at writing your quick experiments that never see the light of day - assuming that you're working in a context where you are already proficient at writing unit tests.
If your quick experiment is of the "let me see if I can integrate these two unfamiliar technologies" sort, then of course unit tests aren't going to be helpful. But if your quick experiment is (or can be) easily testable, then it most likely makes sense to write the tests.
In essence, I'm convinced that "will it go to prod" is completely orthogonal to "should I write tests." Unit tests are there to make development easier. If you want your development to be easier, make a conscious decision about whether the effort to write the tests is justified.
I regularly write tests for the small things I write as experiments, or small tools, things that I "know" will never go to production - how better to test that the experiment/tool/whatever works than with automated tests?
You often also save time by setting up some automated tests, as instead of doing some complicated manual process to test if your stuff works after making changes your unit tests just get triggered automatically (if correctly set up) and will tell you if the code works.
Additionally there is a clear benefit in writing code that is easy to test - it's often better in quality due to readability, less dependencies, less "God object" -type issues, and so on.
This is the most common excuse given to me for not writing tests, and then holy cow, that sucker is in production and people are looking at it daily... too late to write tests, we need more features now!!
Write the damn tests.