4 ms·

I started with XP in 99 after seeing the wars on OTUG, and then made great use of the TDD approach, I was busy using TDD to build real systems by first getting

by keithnz 10y ago

I started with XP in 99 after seeing the wars on OTUG, and then made great use of the TDD approach, I was busy using TDD to build real systems by first getting legacy systems under test and then progressively refactoring and introducing new functionality. At the same time on the mailing lists a lot of the XP consultants started advocating quite "pure" approaches. At first it was "as a learning / thought experiment", but a curious thing started to happen in the 2000s, "Agile" developed a doctrine and religion about it and the free flowing thoughts that were pushing how to design software better started to dry up. A lot of the TDD advice out there at the moment is from the religious stage of Agile. Here's my take-aways on TDD... - It' about designing software through feedback - Code should compose together easily, refactor till it does, be mindful of the tiny details - Test as little as possible (or I think Kent said "as is Responsible"). The tests are there to validate your intent and provide feedback. Tests are liabilities that need to be maintained, so only maintain good ones. learning TDD? do it on throw away problems, play around with how small the steps you can take are. Play around with refactoring, don't have have preconceived ideas about the solution. TDD learning problems with other people. Pay attention how it changes how you design something. Do some bigger things, start noticing the problems of TDD, especially when dealing with outside frameworks and systems. Production TDD? It's a tool and may help provide design ideas or help stitch together preconceived design ideas, use everything in your arsenal to design and create good software, there are no rules or doctrine. But understand as many tools and "rules" that the software community offers and the reasoning behind it. Collaborate with others to create and design, and make sure you have quick feedback cycles. Be quick to recognize new ideas, tools, and techniques that either provide feedback or designs.

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 :)

by keithnz 10y ago

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 :)