11–20 of 33 posts
I have worked in the airline industry with scheduling algorithms. We had a very comprehensive test suite, but reconstructing the algorithms from that would take a decade. That surely only works for toy code bases. No one saves the tests.
I have worked in the airline industry with scheduling algorithms. We had a very comprehensive test suite, but reconstructing the algorithms from that would take a decade. That surely only works for toy code bases. No one saves the tests.
Exactly. Verifying an algorithm is easy. Writing it is hard.
How would you verify that algorithm?
Having test code and dev code in separate repos is a pattern in some places. Where that exists, save the dev code. Any test code that's not allowed to mingle with dev code is highly suspect and almost certainly not a working spec.
Earlier quoted context omitted.
Exactly. Verifying an algorithm is easy. Writing it is hard.
add(a, b) => a + b How would you verify that algorithm?
Forall A:
add(A, 0) == A
Forall A B C:
add(add(A,B), C) == add(A, add(B, C))
Maybe throw in add(A, B) == add(B, A) if you’re angling for a promotion…
> Doesn't matter how good the tests are, by the time you've "reconstructed the code" from tests you're out of business. Running code with no tests makes money. Tests with no running code don't. ^^ comment from someone named hobbs Exactly. Users can tolerate an app that's kinda broken in some ways, but tests don't make money. In fact tests can often cost money anyway if they're not testing what's really important. No…
With that perspective, it's beyond silly to prefer the tests. You are saying "Should I throw away 90% of the work or 10% of the work?"
Said another way, you are asking "Should I save the chapter headings of my book or the content?". I can make new chapter headings, but writing the actual chapters is where I spent all my time.
> More recently, out of curiosity, I pitched the same question as a poll on Twitter. On Twitter, roughly 80% of respondents said that they would save the application code and 20% said they would save the tests. Surprise, common sense. Saving the tests is like needing to know the answer to the Ultimate Question of Life, the Universe, and Everything (which is 42) and discarding the question.
> More recently, out of curiosity, I pitched the same question as a poll on Twitter. On Twitter, roughly 80% of respondents said that they would save the application code and 20% said they would save the tests. Surprise, common sense. Saving the tests is like needing to know the answer to the Ultimate Question of Life, the Universe, and Everything (which is 42) and discarding the question.
I'm shocked that 20% of devs value tests over working code. This should have been a 99% to 1% thing.
Earlier quoted context omitted.
add(a, b) => a + b How would you verify that algorithm?
Forall A: add(A, 0) == A Forall A B C: add(add(A,B), C) == add(A, add(B, C)) I think that’s sufficient. Rule 101 of useful testing is understanding the actual constraints you rely on. Maybe throw in add(A, B) == add(B, A) if you’re angling for a promotion…
add(a, b) => a == 1 && b == 1 ? 1 : a + b
I just refuse to write tests. I think it is complete waste of time.
Here, I said it.
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.
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'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.
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.
Writing tests after 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'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't have to go back to it.
Spending a lot of time now 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.
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.
So it kinda seems it doesn'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.
Instead I am spending effort now to edit all those unit tests for a speculative benefit of saving some time later, and likely less than I am spending now.
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.
Why the bad state of unit tests? I think reasons are quite simple:
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't seem to be immediately improving the product. About the same reason why most documentation is shitty and out of date.
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.
3. If the deadline is looming, what do you think is getting cut first? Expect absolute least effort into writing tests or documentation.
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.
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.