I see many make the mistake of asking managers and product owners permission to do things they deem neccassary for the health and stability of the project. I never ask if I can write tests or do TDD, its just part of my estimate of entire task. Just like a doctor won't ask you, "Do you mind if I wash my hands before the surgery? Its going to take an extra 15 minutes."
One thing to keep in mind when we talk "unit" tests. There is wide range of ideas of what "unit" means. Really when we talk about testing, we want to have a suit of tests that I can run on my local machine that at most will take a minute or less to run. I use TDD and this is important because of the red, green , refactor loop. If the tests for the part of the code I work on take longer then a few seconds, that slows me down. I need quick feedback loops so I can make progress. The longer the tests take to run, the longer my red, green, refactor loops get, the less work I can get done. Or worse, people stop running the tests.
Your automated suite of functional tests may be fitting these needs if any developer can run them on any machine at any time and at most takes a couple minutes to run all the tests. If this is not the case then you may want to look into using "unit" tests.
This is really good point Michael! Testing and documentation are both crucial parts of software development, not just something you add if there's time. Unfortunately many managers only measure things in short-term and either don't care or don't know how to measure the long tail of work that bad code and documentation cause.
Sometimes lack of tests makes it super slow to add new code because you're worried it will break things. Sometimes lack of documentation wastes days of developer time that could have been avoided by minutes or hours of work up ahead.
I see many make the mistake of asking managers and product owners permission to do things they deem neccassary for the health and stability of the project. I never ask if I can write tests or do TDD, its just part of my estimate of entire task. Just like a doctor won't ask you, "Do you mind if I wash my hands before the surgery? Its going to take an extra 15 minutes."
One thing to keep in mind when we talk "unit" tests. There is wide range of ideas of what "unit" means. Really when we talk about testing, we want to have a suit of tests that I can run on my local machine that at most will take a minute or less to run. I use TDD and this is important because of the red, green , refactor loop. If the tests for the part of the code I work on take longer then a few seconds, that slows me down. I need quick feedback loops so I can make progress. The longer the tests take to run, the longer my red, green, refactor loops get, the less work I can get done. Or worse, people stop running the tests.
Your automated suite of functional tests may be fitting these needs if any developer can run them on any machine at any time and at most takes a couple minutes to run all the tests. If this is not the case then you may want to look into using "unit" tests.
This is really good point Michael! Testing and documentation are both crucial parts of software development, not just something you add if there's time. Unfortunately many managers only measure things in short-term and either don't care or don't know how to measure the long tail of work that bad code and documentation cause.
Sometimes lack of tests makes it super slow to add new code because you're worried it will break things. Sometimes lack of documentation wastes days of developer time that could have been avoided by minutes or hours of work up ahead.
Speaking the truth here, I cannot count how many example I have of untested code that produce side effects over time...