4 ms·

> the result is usually an untested, and usually nearly untestable No way... if you ever wrote any tests, you can easily know how to write code that will be te

by brabel 5y ago

> the result is usually an untested, and usually nearly untestable No way... if you ever wrote any tests, you can easily know how to write code that will be testable even if you do it later. Doing it before is just going to be a big waste of time if you throw the code away later, which happens a lot when you need to experiment with things before actually choosing what works best. Yes, you can do that with TDD as well but it will absolutely slow you down. If you end up not writing tests later, when the implementation has been chosen, it's just because you don't care about the code quality... I find it hard to believe TDD will fix you in that case.

regularfry 5y ago
Swings and roundabouts: what you lose on writing tests you gain on not bothering to implement things you don't need. If the test passes, you stop. Without the tests to guide you it's very easy to waste time over-engineering, even if what you're building is well-structured.
- brabel 5y ago
  I often write code without implementing anything, just the "surface API". That's when I find whether things will work or not. Tests are a hindrance to that. Once I figure out the design, then I will test all that I think is important. > what you lose on writing tests you gain on not bothering to implement things you don't need. I am not sure where to start... I've written so much code, applications, libraries, algorithms... and I am pretty sure the opposite of what you say is true: with TDD, I would've spent hours trying to get something working that later I would find, by exploration, that I didn't need at all.
  - regularfry 5y ago
    > I often write code without implementing anything, just the "surface API". That's when I find whether things will work or not. There's an entire school of TDD which works this way. That's not incompatible at all. > with TDD, I would've spent hours trying to get something working that later I would find, by exploration, that I didn't need at all. If you're writing tests for something you don't need, the problem isn't with TDD as I understand it.
berkes 5y ago
I've always experienced that writing the actual code is but a minor part of building features (or fixing bugs). Especially when prototyping, which most often is merely ducttaping libs together. Everyone remembers a bugfix of one line, that took hours, or days to find. I'd stringly encourage you to check your commitlogs. You'll probably find you commit at most hundreds of lines a day, quite probably, as is my case too, av era aging under ten lines a day. Please stop thinking that writing code which does not make it into commits, is waste. It is learning. And tests are by far the best place to learn about your, and Libs' code, APIs and behaviour.

by brabel 5y ago

regularfry 5y ago

Swings and roundabouts: what you lose on writing tests you gain on not bothering to implement things you don't need. If the test passes, you stop. Without the tests to guide you it's very easy to waste time over-engineering, even if what you're building is well-structured.

brabel 5y ago
I often write code without implementing anything, just the "surface API". That's when I find whether things will work or not. Tests are a hindrance to that. Once I figure out the design, then I will test all that I think is important. > what you lose on writing tests you gain on not bothering to implement things you don't need. I am not sure where to start... I've written so much code, applications, libraries, algorithms... and I am pretty sure the opposite of what you say is true: with TDD, I would've spent hours trying to get something working that later I would find, by exploration, that I didn't need at all.
- regularfry 5y ago
  > I often write code without implementing anything, just the "surface API". That's when I find whether things will work or not. There's an entire school of TDD which works this way. That's not incompatible at all. > with TDD, I would've spent hours trying to get something working that later I would find, by exploration, that I didn't need at all. If you're writing tests for something you don't need, the problem isn't with TDD as I understand it.

berkes 5y ago

I've always experienced that writing the actual code is but a minor part of building features (or fixing bugs). Especially when prototyping, which most often is merely ducttaping libs together. Everyone remembers a bugfix of one line, that took hours, or days to find. I'd stringly encourage you to check your commitlogs. You'll probably find you commit at most hundreds of lines a day, quite probably, as is my case too, av era aging under ten lines a day. Please stop thinking that writing code which does not make it into commits, is waste. It is learning. And tests are by far the best place to learn about your, and Libs' code, APIs and behaviour.