Save the code or save the tests? (2020)
I see how I am going to be downvoted to hell, but let&#x27;s give it a shot:<p>I just refuse to write tests. I think it is complete waste of time.<p>Here, I said it.<p>My preferred style of working is writing something and then refactoring it to my satisfaction. I toy with interfaces as I discuss meaning of various things, learning in the process. I am mercilessly cutting stuff that is not necessary, finding ways to make everything shorter, simpler, easier to understand. In the process I am constantly moving stuff around, changing concepts for other concepts, removing code that has already been written that I find no longer necessary, etc.<p>Writing tests might make sense if you know how the code will be structured, what is going to be exact contract for that method, and so on. It doesn&#x27;t make sense if you are going to be changing it in a moment, multiple times, with 20% probability you are going to remove it anyway.<p>I tried to give it a shot, but writing tests breaks my flow as I try to put some kind of structure as quickly as possible and then when I am polishing it to perfection.<p>Writing tests <i>after</i> the code has been written seems like a waste of time for another reason. I have already written the code and thought through the contract. Writing complete unit test suite would take about as much time as time necessary to write the code in the first place. But if I put so much time writing that code correctly there is relatively little chance somebody is going to be reworking it. That&#x27;s basically the whole point, to make it less likely that it is going to be hotspot of work in the future. I put effort in that module so that I don&#x27;t have to go back to it.<p>Spending a lot of time <i>now</i> to have some probability it is going to save some amount of time in the future, most likely less or comparable with the amount of time invested in the tests -- total waste of time.<p>Later, assuming I actually try to refactor code that is tested, the tests are getting in my way. Thanks to tools like IDE I can edit a lot of code efficiently and with high degree of reliability. I can move stuff around, simplify, then move again, then simplify again and so on. But there is still no automation to correct unit tests accordingly -- every time I changed the structure of the code significantly I have to go to correct those tests.<p>So it kinda seems it doesn&#x27;t help me with the refactoring task either. There might be a chance I make a mistake that could have been caught by a unit test -- but my experience shows that it is rather rare occasion that a unit tests prevents me from doing something stupid.<p>Instead I am spending effort <i>now</i> to edit all those unit tests for a speculative benefit of saving some time later, and likely less than I am spending now.<p>Add to that that most codebases I have seen in the past consist mostly of bullshit unit tests -- tests that are there only to prop up test coverage to a level required by CI pipeline and usually test only simplest parts of the contract or even plainly stuff that is completely self explanatory.<p>Why the bad state of unit tests? I think reasons are quite simple:<p>1. If the test is written after the code it means the developer has already written the code and is now not that much interested in doing something else that doesn&#x27;t seem to be immediately improving the product. About the same reason why most documentation is shitty and out of date.<p>2. Production code is constantly being tested and there is feedback if it is not correct. There is no feedback if tests are not correct. The only real requirement for unit tests is that they pass and that there is enough of them.<p>3. If the deadline is looming, what do you think is getting cut first? Expect absolute least effort into writing tests or documentation.<p>4. It is hard enough to get developers to review production code. I have yet to see a reviewer that would do anything else than skip or only gloss over test code.<p>Having to make a choice -- do I want more well written code or less code but with test coverage that is most likely going to bring little value... my choice is rather simple.