3 ms·

This sounds awful. In fact, TDD as a whole is awful. I'm a developer, I can make any awful code pass any test I want.

by axaxs 6y ago

alpaca128 6y ago
> I'm a developer, I can make any awful code pass any test I want. How is that statement exclusive to TDD or something that makes TDD unviable? TDD isn't about trying to pass some tests no matter how. It's supposed to make you think through the problem and define the interfaces before writing the actual code, when it's still very easy to rearrange and adapt the structure. So that the end result is not awful in the first place.
- axaxs 6y ago
  I think it's just a paradigm difference. For me at least, I think better about tests -after- implementation. A short example. Let's say I had to write a hash function. If I were forced to write a test for it up front, I'd probably do something naive like ensuring the result of hashing("abc") was 123. Now I start on my code. Oh, I need to return 123, easy enough. Tests pass, ship it! If I implemented the function first, I'd then think about pitfalls -in- the code. Let's give it weird input. Let's give it empty things. Let's make sure that for 1000 random strings, the hashes are different. Things like that, because those are things I think about when -implementing- the code, and typically not prior. I'm not saying that to be snide, that's really how my brain would work. I understand everyone is different, so I'm only speaking for myself.
mjfisher 6y ago
I can go one better, and make any program at all compile by removing code with the annoying wiggly red lines under it. The tools and options we have don't exist in a vacuum; you still need good judgement and practice to make the most of them.
- axaxs 6y ago
  It's funny you say that. Not long ago, one fresh dev was tasked with linting old code. Their first pass was to delete everything that the linter complained about. Hey, I guess they solved the problem!
l0b0 6y ago
I'm sorry you feel that way. It took until I got a good mentor, after almost a decade as a developer, before I got an actual good introduction to TDD. Before that I just didn't see the point. Since then, that's how I do all my work. It's just extremely satisfying to have almost complete confidence that the code will work in production on the first try.
- sah2ed 6y ago
  > It's just extremely satisfying to have almost complete confidence that the code will work in production on the first try. I agree that TDD has enormous benefits when used with discipline, but remember to temper your expectations as to the actual purpose of tests. The fact that your tests pass doesn’t mean your app is bug free—it is only free of the bugs you were able to test for. There’s a concise but somewhat counterintuitive quote from Dijkstra that summarizes what tests help you uncover: ”Program testing can be used to show the presence of bugs, but never to show their absence!” https://en.wikiquote.org/wiki/Edsger_W._Dijkstra#1970s https://en.wikiquote.org/wiki/Edsger_W._Dijkstra#1970s
  - l0b0 6y ago
    This isn't aimed at you personally, but I find it tedious how this is pointed out every time testing comes up. It is just not relevant, because I've never claimed that TDDed code is bug free, and I've never seen anyone else claim that. It would be ludicrous. Most of the time it is used as some sort of "proof" that TDD or even testing in general is useless, because if it doesn't guarantee bug-free code there's no way it adds any value.

This sounds awful. In fact, TDD as a whole is awful. I'm a developer, I can make any awful code pass any test I want.

by axaxs 6y ago

This sounds awful. In fact, TDD as a whole is awful. I'm a developer, I can make any awful code pass any test I want.

> I'm a developer, I can make any awful code pass any test I want. How is that statement exclusive to TDD or something that makes TDD unviable? TDD isn't about trying to pass some tests no matter how. It's supposed to make you think through the problem and define the interfaces before writing the actual code, when it's still very easy to rearrange and adapt the structure. So that the end result is not awful in the first place.

axaxs 6y ago
I think it's just a paradigm difference. For me at least, I think better about tests -after- implementation. A short example. Let's say I had to write a hash function. If I were forced to write a test for it up front, I'd probably do something naive like ensuring the result of hashing("abc") was 123. Now I start on my code. Oh, I need to return 123, easy enough. Tests pass, ship it! If I implemented the function first, I'd then think about pitfalls -in- the code. Let's give it weird input. Let's give it empty things. Let's make sure that for 1000 random strings, the hashes are different. Things like that, because those are things I think about when -implementing- the code, and typically not prior. I'm not saying that to be snide, that's really how my brain would work. I understand everyone is different, so I'm only speaking for myself.

mjfisher 6y ago

I can go one better, and make any program at all compile by removing code with the annoying wiggly red lines under it. The tools and options we have don't exist in a vacuum; you still need good judgement and practice to make the most of them.

axaxs 6y ago
It's funny you say that. Not long ago, one fresh dev was tasked with linting old code. Their first pass was to delete everything that the linter complained about. Hey, I guess they solved the problem!

l0b0 6y ago

I'm sorry you feel that way. It took until I got a good mentor, after almost a decade as a developer, before I got an actual good introduction to TDD. Before that I just didn't see the point. Since then, that's how I do all my work. It's just extremely satisfying to have almost complete confidence that the code will work in production on the first try.

sah2ed 6y ago
> It's just extremely satisfying to have almost complete confidence that the code will work in production on the first try. I agree that TDD has enormous benefits when used with discipline, but remember to temper your expectations as to the actual purpose of tests. The fact that your tests pass doesn’t mean your app is bug free—it is only free of the bugs you were able to test for. There’s a concise but somewhat counterintuitive quote from Dijkstra that summarizes what tests help you uncover: ”Program testing can be used to show the presence of bugs, but never to show their absence!” https://en.wikiquote.org/wiki/Edsger_W._Dijkstra#1970s https://en.wikiquote.org/wiki/Edsger_W._Dijkstra#1970s
- l0b0 6y ago
  This isn't aimed at you personally, but I find it tedious how this is pointed out every time testing comes up. It is just not relevant, because I've never claimed that TDDed code is bug free, and I've never seen anyone else claim that. It would be ludicrous. Most of the time it is used as some sort of "proof" that TDD or even testing in general is useless, because if it doesn't guarantee bug-free code there's no way it adds any value.