5 ms·

That's why the red-green-refactor style of TDD is so useful. You start by writing a failing test, then make it pass with the simplest possible change, and then

by l0b0 8y ago

That's why the red-green-refactor style of TDD is so useful. You start by writing a failing test, then make it pass with the simplest possible change, and then refactor the code while keeping everything passing. You'd be hard pressed to write a test which fails and then passes by accident. It leads to extremely clean code IME.

mlthoughts2018 8y ago
In my experience this approach offers nothing, because the whole challenge is in writing the right tests, and you almost never know what the test is supposed to be like until after writing code for a while. There’s a symbiosis between knowing what test needs to be written and knowing what code needs to be written. No part of specs, TDD, BDD, etc., actually ever captures the reality of this, despite every Name Brand Workflow always claiming to.
- l0b0 8y ago
  > There’s a symbiosis between knowing what test needs to be written and knowing what code needs to be written. This should only be the case while unfamiliar with the language or project at hand. In my experience, once you're familiar with the project and the language, mulling over a requirement for a short time should be enough to split it into smaller features which are simple to test in isolation.
  - mlthoughts2018 8y ago
    It has pretty much nothing to do with your experience level, your familiarity with the project or the language or tooling. When those things matter, they amplify this phenomenon, but the baseline effect is already high. It’s a function of requirements being ambiguous by design. Non-engineering stakeholders have a severe need for requirements and specs to be fungible and ambiguous, such that whether or not the state of the project satisfies requirements is fundamentally not codified in any objective document and no test can reflect useful objective measures of it. Tests can only loosely approximate it and the ways to do so are always shifting and changing and up to a subjective interpretation of some non-technical people. Perhaps the only objective measure that non-tech people will agree to be specific about is financial cost, and even then usually only after it becomes a problem. That’s every project in a product-oriented tech company period, and anyone claiming otherwise is full of it. There can be isolated, tiny pockets of maintenance work or last stages dev work once you pass a point of no return when business people can no longer sustainable lobby for requirements to continue to be ambiguous and fungible, and finally you can start proving things with accurately scoped tests, but it’s so late in the game that the idea you could do something like TDD at that point is comical. Instead, becoming a good product-oriented developer means in part learning how to write well factored tests on the fly at the same time you are writing the code to be tested, and keeping testing code clean and set up with fixtures and set up to run in highly automated ways, so that when you’re inevitably ripping stuff out of the implementation for the 18th time due to yet another priority pivot from sales, you can nimbly also update the tests as you go.
    - l0b0 8y ago
      I'm sorry you're going to feel I'm full of it, but I've seen TDD work in three different companies. Of course, TDD is not going to fix broken project management such as blindly trying to second guess vague requirements. Other types of QA are also necessary, including (but not limited to) client UAT and sign-off on features, to make sure you're continuously working towards something the client would want to use.
      - mlthoughts2018 8y ago
        I appreciate the comment but for me seeing is believing. I’ve heard many people make claims like yours, but across 5 “enterprise” software jobs at large companies (many thousands of engineers) and 2 jobs at medium startups ~10 yrs old and 300+ engineers, I’ve never ever seen any type of formal methodology make any impact or difference of any kind. I’ve only ever seen non-engineers arguing about process crap and making claims like this, while engineers are forced to learn a bizarre skill set of how to actually solve problems despite this quarter’s latest and greatest new process thingy that’s going to fix it all.
    - jdlshore 8y ago
      I've been using TDD for years (since 2000!) and my experience doesn't match yours. I've used it on countless projects, big and small. I think the disconnect is that you're assuming the tests are about requirements, when in fact the tests people write with TDD are much more tightly focused.
      - mlthoughts2018 8y ago
        > “in fact the tests people write with TDD are much more tightly focused.” This usually doesn’t help and sometimes hurts, because if the tests are tighlty scoped yet the requirements are ambiguous, it usually means the tests are very related to the current implementation details, which are going to rapidly change due to scope pivots. TDD simply doesn’t work when you don’t know what tests to write or how to structure tests to accomodate scope and priority changes, which is all the time. Starting out by writing a test then coding to pass that test is baking in an assumption about that test which is almost surely already wrong, and just creates rework to undo a tightly focused test.

by l0b0 8y ago

mlthoughts2018 8y ago

In my experience this approach offers nothing, because the whole challenge is in writing the right tests, and you almost never know what the test is supposed to be like until after writing code for a while. There’s a symbiosis between knowing what test needs to be written and knowing what code needs to be written. No part of specs, TDD, BDD, etc., actually ever captures the reality of this, despite every Name Brand Workflow always claiming to.

l0b0 8y ago
> There’s a symbiosis between knowing what test needs to be written and knowing what code needs to be written. This should only be the case while unfamiliar with the language or project at hand. In my experience, once you're familiar with the project and the language, mulling over a requirement for a short time should be enough to split it into smaller features which are simple to test in isolation.
- mlthoughts2018 8y ago
  It has pretty much nothing to do with your experience level, your familiarity with the project or the language or tooling. When those things matter, they amplify this phenomenon, but the baseline effect is already high. It’s a function of requirements being ambiguous by design. Non-engineering stakeholders have a severe need for requirements and specs to be fungible and ambiguous, such that whether or not the state of the project satisfies requirements is fundamentally not codified in any objective document and no test can reflect useful objective measures of it. Tests can only loosely approximate it and the ways to do so are always shifting and changing and up to a subjective interpretation of some non-technical people. Perhaps the only objective measure that non-tech people will agree to be specific about is financial cost, and even then usually only after it becomes a problem. That’s every project in a product-oriented tech company period, and anyone claiming otherwise is full of it. There can be isolated, tiny pockets of maintenance work or last stages dev work once you pass a point of no return when business people can no longer sustainable lobby for requirements to continue to be ambiguous and fungible, and finally you can start proving things with accurately scoped tests, but it’s so late in the game that the idea you could do something like TDD at that point is comical. Instead, becoming a good product-oriented developer means in part learning how to write well factored tests on the fly at the same time you are writing the code to be tested, and keeping testing code clean and set up with fixtures and set up to run in highly automated ways, so that when you’re inevitably ripping stuff out of the implementation for the 18th time due to yet another priority pivot from sales, you can nimbly also update the tests as you go.
  - l0b0 8y ago
    I'm sorry you're going to feel I'm full of it, but I've seen TDD work in three different companies. Of course, TDD is not going to fix broken project management such as blindly trying to second guess vague requirements. Other types of QA are also necessary, including (but not limited to) client UAT and sign-off on features, to make sure you're continuously working towards something the client would want to use.
    - mlthoughts2018 8y ago
      I appreciate the comment but for me seeing is believing. I’ve heard many people make claims like yours, but across 5 “enterprise” software jobs at large companies (many thousands of engineers) and 2 jobs at medium startups ~10 yrs old and 300+ engineers, I’ve never ever seen any type of formal methodology make any impact or difference of any kind. I’ve only ever seen non-engineers arguing about process crap and making claims like this, while engineers are forced to learn a bizarre skill set of how to actually solve problems despite this quarter’s latest and greatest new process thingy that’s going to fix it all.
  - jdlshore 8y ago
    I've been using TDD for years (since 2000!) and my experience doesn't match yours. I've used it on countless projects, big and small. I think the disconnect is that you're assuming the tests are about requirements, when in fact the tests people write with TDD are much more tightly focused.
    - mlthoughts2018 8y ago
      > “in fact the tests people write with TDD are much more tightly focused.” This usually doesn’t help and sometimes hurts, because if the tests are tighlty scoped yet the requirements are ambiguous, it usually means the tests are very related to the current implementation details, which are going to rapidly change due to scope pivots. TDD simply doesn’t work when you don’t know what tests to write or how to structure tests to accomodate scope and priority changes, which is all the time. Starting out by writing a test then coding to pass that test is baking in an assumption about that test which is almost surely already wrong, and just creates rework to undo a tightly focused test.