3 ms·

I call those "implementation tests", and I delete the tests once I have finished the implementation. From experience, what you care about in that case is to ma

I call those "implementation tests", and I delete the tests once I have finished the implementation. From experience, what you care about in that case is to make sure you implemented the private functions correctly, because it might be some tricky algorithm or whatever. Tests with a lower granularity than the public API make a lot of sense to achieve that goal, it's pretty similar to TDD (though you do not necessarily have the write the tests before the code). On the other hand, in the vast majority of cases, the code, once written, will not be changed. If the public API is changed, then it's likely the internal implementation will be replaced, or changed. In any case, the "implementation tests" will break because the contract has changed. So I delete them, the maintenance cost is higher than the long term value they bring, and non-regression should be ensured by the public API tests anyway. Sometimes, this is wrong, and you will actually need to extend the code in such a way that keeping the "implementation tests" would have helped. I haven't found a good way there to store the test "just in case". You could for instance have a commit that adds them then a commit that removes them, but this is a lot of noise in the history, and the probability that anyone but you can find the deleted tests if they need them is pretty much 0.

jcelerier 5y ago
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.
- Leherenn 5y ago
  > Why would you ever remove a test ? 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.
  - throwawayninja 5y ago
    > Every extra line of code is debt. 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.
  - galaxyLogic 5y ago
    > Every extra line of code is debt. 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.

jcelerier 5y ago

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.

Leherenn 5y ago
> Why would you ever remove a test ? 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.
- throwawayninja 5y ago
  > Every extra line of code is debt. 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.
- galaxyLogic 5y ago
  > Every extra line of code is debt. 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.