3 ms·

oh, one other thought, if you are a TDD advocate and TDD all the time and are quite productive. Try this, code something without tests. A curious thing occurs

by keithnz 10y ago

oh, one other thought, if you are a TDD advocate and TDD all the time and are quite productive. Try this, code something without tests. A curious thing occurs, your software mostly works fine, it's often correct straight away. Basically, you learnt how to design and code. The tests are just feedback. The code itself should also be surprisingly testable if you wanted to test it (if not, still lessons to learn about design and coding). Now, since you are coding and designing pretty well without tests, pay attention to what actually breaks. Gives you a good idea about what kind of Tests are important. Then think about the minimal test that would have stopped you making the mistake.

DanielBMarkham 10y ago
I think what led to the religious zeal currently is that OO/mutable state programming is a house of cards. On a team, everybody can be a great coder, but just one bug can bring the whole thing down in a non-trivial manner. I'm guessing it was easier simply to say "TDD All The Things!" than try to split hairs and work with the nuance.
- dasmoth 10y ago
  This seems to be anathema in some circles, but perhaps the team (in the abstract) is the problem here. Rather than bending over backwards to make software development team-friendly, might it make more sense to have individual module owners and well-defined interfaces between modules? (Trying to compartmentalise the mutable state wouldn't hurt, either...)
- keithnz 10y ago
  what drove the religion was this rejection of the "Big Design Up Front" (BDUF). in 99, Rationals Unified Process ( RUP ) was seen as mind meld of best design advice and process ( in a so called process framework ) which advocated a phase of pure design using UML notation. Any notion of design up front was countered with TDD, and long talks about emergence :) I think it was a good counter balance and it brought in the age of quick feedback and continuous delivery.
mdpopescu 10y ago
In my experience, by the time I got to "the code breaks" it's because it's a horrible mess. I'm a good programmer, if I write good code it doesn't break :) Every time I wrote code without TDD I regretted it. Every freaking time. Even on small, two-day projects (which became three-month projects which became two-years projects).
- DanielBMarkham 10y ago
  I wouldn't write commercial OO/mutable-state code without TDD. Not all code is like that. My point wasn't about being a good programmer, although that's what the parent said. My point was that OO itself is inherently a nest of snakes, where a lot of damned good coding can amount to jack squat because of one error. So yes, we agree. In OO, you screw up one piece on a class somewhere? It could hose up systems near and far. In fact, in many cases it's impossible to predict just what you've screwed up. In pure FP, you screw up one piece of code? That piece is screwed up. Everything else continues to work just fine. In OO it becomes more and more imperative to use TDD the larger and more non-trivial the codebase is. Talking about how you only use it is great. It's also pretty cool to understand why this should be true -- and be able to explain the edge cases. It's very easy to sound like one of those religious folks we're talking about when you don't mean it that way :)
  - waterlink 10y ago
    Interestingly, enough, my OO code, when I refactor it well, mostly consists of tiny little (one-public-methods) classes, 99% of them are stateless, and, usually, 3-5 are composed to accomplish any sort of task at any level of the detail. I started writing OO code this way only after learning Haskell and having production experience with Clojure. Basically, immutable objects are very similar to pure functions and easier to reason about. Even in pure functional environments I do use TDD, because it gives me enough confidence to know, that I know what I am doing. Maybe it is just a mindset, or my brain is wired this way. For any change to the production code I require a proof, that system needs to be changed in a form of failing test.
    - 10y ago
lgunsch 10y ago
I have totally experienced this. I've done TDD nearly exclusively for 4 years now, and I've learned a lot of bad patterns, and a lot of good patterns. Now, if I ever just play around without tests, I find myself using the same patterns as I would with TDD and the code is well structured anyways. I still end up thinking to myself that I will need to test this in the future, so I structure it to be testable because of my developed thought patterns.

by keithnz 10y ago

DanielBMarkham 10y ago

I think what led to the religious zeal currently is that OO/mutable state programming is a house of cards. On a team, everybody can be a great coder, but just one bug can bring the whole thing down in a non-trivial manner. I'm guessing it was easier simply to say "TDD All The Things!" than try to split hairs and work with the nuance.

dasmoth 10y ago
This seems to be anathema in some circles, but perhaps the team (in the abstract) is the problem here. Rather than bending over backwards to make software development team-friendly, might it make more sense to have individual module owners and well-defined interfaces between modules? (Trying to compartmentalise the mutable state wouldn't hurt, either...)
keithnz 10y ago
what drove the religion was this rejection of the "Big Design Up Front" (BDUF). in 99, Rationals Unified Process ( RUP ) was seen as mind meld of best design advice and process ( in a so called process framework ) which advocated a phase of pure design using UML notation. Any notion of design up front was countered with TDD, and long talks about emergence :) I think it was a good counter balance and it brought in the age of quick feedback and continuous delivery.

mdpopescu 10y ago

In my experience, by the time I got to "the code breaks" it's because it's a horrible mess. I'm a good programmer, if I write good code it doesn't break :) Every time I wrote code without TDD I regretted it. Every freaking time. Even on small, two-day projects (which became three-month projects which became two-years projects).

DanielBMarkham 10y ago
I wouldn't write commercial OO/mutable-state code without TDD. Not all code is like that. My point wasn't about being a good programmer, although that's what the parent said. My point was that OO itself is inherently a nest of snakes, where a lot of damned good coding can amount to jack squat because of one error. So yes, we agree. In OO, you screw up one piece on a class somewhere? It could hose up systems near and far. In fact, in many cases it's impossible to predict just what you've screwed up. In pure FP, you screw up one piece of code? That piece is screwed up. Everything else continues to work just fine. In OO it becomes more and more imperative to use TDD the larger and more non-trivial the codebase is. Talking about how you only use it is great. It's also pretty cool to understand why this should be true -- and be able to explain the edge cases. It's very easy to sound like one of those religious folks we're talking about when you don't mean it that way :)
- waterlink 10y ago
  Interestingly, enough, my OO code, when I refactor it well, mostly consists of tiny little (one-public-methods) classes, 99% of them are stateless, and, usually, 3-5 are composed to accomplish any sort of task at any level of the detail. I started writing OO code this way only after learning Haskell and having production experience with Clojure. Basically, immutable objects are very similar to pure functions and easier to reason about. Even in pure functional environments I do use TDD, because it gives me enough confidence to know, that I know what I am doing. Maybe it is just a mindset, or my brain is wired this way. For any change to the production code I require a proof, that system needs to be changed in a form of failing test.
  - 10y ago

lgunsch 10y ago

I have totally experienced this. I've done TDD nearly exclusively for 4 years now, and I've learned a lot of bad patterns, and a lot of good patterns. Now, if I ever just play around without tests, I find myself using the same patterns as I would with TDD and the code is well structured anyways. I still end up thinking to myself that I will need to test this in the future, so I structure it to be testable because of my developed thought patterns.