I find it beyond crazy that you'd go through all this complicated decision state machine when you could just keep the tests and mark them as friends of the class.
Why would you ever remove a test ? You don't know when your platform will change things from under your feet, for instance going from x86 to arm, which may break them in subtle ways without you changing anything to your code. And then you're losing hours searching in your 10k commit history the code that had been removed.
Because the cost of building/running/maintaining and generally just having the test around is higher than the value I get from the test. And because I still have unit tests on the public function that should catch issues. Really, I just wrote them to help me during the dev part. Every extra line of code is debt.
> And then you're losing hours searching in your 10k commit history the code that had been removed.
You're right, I said it was a possibility, but I don't do that, it's not worth it. It has happened twice so far I think that I wished I hadn't removed the tests. I bit the bullet and rewrote them, which is okay because of how rare it is.
I think you are right, unneeded tests are debt especially because implementation evolves during development (and maintenance) which often means you have to rewrite the tests if you modify the implementation, or when you change the division of labor between public and private methods.
Sage wisdom, I wish managers took this up a little. They'd improve throughput by 10x or so in a week, and new developers would have shorter lead times. Plus quality would go up, the fastest most correct code is the stuff you never write.
Why would you ever remove a test ? You don't know when your platform will change things from under your feet, for instance going from x86 to arm, which may break them in subtle ways without you changing anything to your code. And then you're losing hours searching in your 10k commit history the code that had been removed.