Comment by specialist
2 days ago
Do you mean the relevant code area(s) didn't have (sufficient) tests? You're being asked to backfill those missing tests in addition to your fix?
2 days ago
Do you mean the relevant code area(s) didn't have (sufficient) tests? You're being asked to backfill those missing tests in addition to your fix?
Yes. I've experienced pushback from obvious fixes with requests to formally test their code for the first time.
All because it may break someone. Even when I presented a real defect based on docs/comments and fixed it. You'd think that if they truly cared about breakages they'd already have some tests for it from where I can easily start.
I don’t think that is necessarily unreasonable. The team may have the same constraints on themselves in that they wouldn’t touch the code either until tests are written.
> All because it may break someone. Even when I presented a real defect based on docs/comments and fixed it.
It's great that you found a bug and fixed it.
The problem is, how do you know that there are no other regressions?
Code is a liability. Once you check it in, the team that owns it is responsible for it. Untested code is a liability of unknown scope. It's quite understandable why they don't want to accept someone's contributions, when the contributor isn't the one who will ultimately be dealing with any of the consequences. If you think they are being mean and lazy, imagine if the tables were reversed.
I don't accept puppies or elephants as gifts for similar reasons.
It's unfortunate that existing test coverage sucks. In this case, the best way forward should be for the team in question to improve coverage, and for you to then submit your fix + a test for it. And if they don't have budget to do this, then that sucks, but that's their call to make, and that's a signal that the project in question is abandonware.
And it's fine for a large company to have a bunch of abandonware. If it works, and produces value, the optimal amount of ongoing development effort to invest into a piece of software may, depending on the circumstances, be near-zero.