The problem is that project is likely not well equipped to handle unit tests after the fact. The unit tests will likely have lots of dependencies and run slowly. The only remedy is to refactor the code base to be easier to test. However, the refactoring of code without unit tests is extremely risky. This is a vicious circle.
That is why you use integration tests on the old code and unit tests on the new one you add or refactor because, as you said, unit tests on legacy unmaintainable code is madness.
Right, but that involves writing the integration test (assuming one doesn't exist). This gives the developer three options:
1. Write the Integration Test to refactor the code to write the unit test.
The "best" option but most time consuming.
2. Write the Integration Test instead of the unit test.
The code is at least tested, but the test is brittle and slow.
3. Fix the bug and skip the unit test (just this one time!)
Unfortunately probably the most common. A Developer will likely rationalize that this small bug is not important enough to do all the work in option 1.
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.
The problem is that project is likely not well equipped to handle unit tests after the fact. The unit tests will likely have lots of dependencies and run slowly. The only remedy is to refactor the code base to be easier to test. However, the refactoring of code without unit tests is extremely risky. This is a vicious circle.
You right, when the code base is not sane, unit tests will not add any value to the project.
That is why you use integration tests on the old code and unit tests on the new one you add or refactor because, as you said, unit tests on legacy unmaintainable code is madness.
Right, but that involves writing the integration test (assuming one doesn't exist). This gives the developer three options:
1. Write the Integration Test to refactor the code to write the unit test.
The "best" option but most time consuming.
2. Write the Integration Test instead of the unit test.
The code is at least tested, but the test is brittle and slow.
3. Fix the bug and skip the unit test (just this one time!)
Unfortunately probably the most common. A Developer will likely rationalize that this small bug is not important enough to do all the work in option 1.