Is it really possible to cover untested code?
And to cover years of code that is untested which also means it was not designed to be testable and therefore is tough to test?
From my experience, in the end we cover new features (that do not rely on too much old code) and easy to test code (helper classes or very small modules).
Covering the whole thing takes tremendous time not only of test writing but also massive refactoring to get it to be testable. Problem is, we do not have tests to cover our asses while refactoring so the risk is really high.
Of course keeping untested old code is risky too...
At the end of the day, I believe that being in the situation of a big codebase with very little testing is awful with very little hope of improvement (does not mean we should not try)...
s it really possible to cover untested code?
And to cover years of code that is untested which also means it was not designed to be testable and therefore is tough to test?
I'd go with the Scouts mentality of leaving code better than you found it. Add tests when you're touching a piece of code, so you can already edit it to be more testable. Yes that might be a slightly risky refactor because it's not covered by tests, but then again, it's no more risky than the development you did before TDD.
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.
Is it really possible to cover untested code?
And to cover years of code that is untested which also means it was not designed to be testable and therefore is tough to test?
From my experience, in the end we cover new features (that do not rely on too much old code) and easy to test code (helper classes or very small modules).
Covering the whole thing takes tremendous time not only of test writing but also massive refactoring to get it to be testable. Problem is, we do not have tests to cover our asses while refactoring so the risk is really high.
Of course keeping untested old code is risky too...
At the end of the day, I believe that being in the situation of a big codebase with very little testing is awful with very little hope of improvement (does not mean we should not try)...
I'd go with the Scouts mentality of leaving code better than you found it. Add tests when you're touching a piece of code, so you can already edit it to be more testable. Yes that might be a slightly risky refactor because it's not covered by tests, but then again, it's no more risky than the development you did before TDD.