3 ms·
I haven't shared this on HN but I saw this on another forum and thought this was a really fantastic example of what you can end up with, in the real world, when
by logicallee 9y ago
I haven't shared this on HN but I saw this on another forum and thought this was a really fantastic example of what you can end up with, in the real world, when you are driven by tests. Real-world example:
https://i.redd.it/lwin56fisdsz.png https://i.redd.it/lwin56fisdsz.png
It doesn't look like a joke to me. It only works over integers so the code is absolutely correct.
It also strikes me as the kind of convoluted logic that someone took a really, really long time to come up with, before it finally worked. (As indicated in the comment.)
A test can hardly capture what's wrong with this code. But any human can see it instantly. (And it's kind of weird that the programmer didn't.) I think most people can think of braindead decisions that are not really captured by testing.
- UncleMeat 9y agoAre there any proponents of serious testing or tdd that don't also promote code review? Why would tests make this code more likely? If anything, I am more confident that I can change it to be better if I have a test suite.
- ngoede 9y agoYeah the way to write better code is to write better code. I happen to find TDD a useful tool in that but doing things badly is still possible. Someone mentioned DI not getting rid of coupling and I agree. DI is a tool you might use but the way to get rid of coupling is not one simple thing but a process of a bunch of different tools and techniques. You can't just slavishly fallow some process and expect it to fix all your issues. You have to think and do work yourself to fix it.
- logicallee 9y ago>Why would tests make this code more likely? Code like this is basically only possible through testing, because the programmer doesn't understand why it is working: it says so in the comment, which I believe. So if it weren't written against testing (manual or automatic) it simply couldn't be written like this. There are a lot of really broken designs that "work". Testing gets you "working" code. Often you could do much better starting with correct code and then adding testing afterward - which I believe is not the essence of TDD. TDD is about driving the writing of code by tests, and I believe the example I shared is one of these bad outcomes. (There are others.)