5 ms·

"TDD is not an option" and yet,at the same breath ".. unit tested.."? I'm puzzled, care to elaborate the logic behind your statements?

by jander 11y ago

mlpinit 11y ago
my understanding: instead of driving by writing tests first, they first write the implementation and then they test.
- philbarr 11y ago
  And definitely if the team agree they don't like TDD, don't force it onto them. In this situation at least.
  - jander 11y ago
    Assuming they have a solid and reasonable argument against it and not just hand-waving and throwing toys out of the pram :-) . In which case, if they do, I would love to see it.
    - jakubp 11y ago
      The burden of proof usually lies on the person suggesting a change to an existing process. What arguments would you give to try to convince someone to do TDD? Because arguments against can be really simple and reasonable: "it's a risky change that will slow us down without obvious upsides", "we don't like to change, it's effortful, and stressful", "we don't have the skills to do it" etc. And that can be told of ANY change of any process/routine! So what would you say to a team of developers if you wanted to persuade them to do TDD? (or to a manager who has influence on them)
      - crdoconnor 11y ago
        >The burden of proof usually lies on the person suggesting a change to an existing process. What arguments would you give to try to convince someone to do TDD? Arguments don't work. You need to build the tools that let your developers actually write sensible tests (i.e. tests which mimic user stories). Once the tools are there the process becomes fairly natural and the upsides become obvious. Some people call this BDD. It doesn't really matter what it's called, but it's generally a faster and less risky approach to programming.
    - alextgordon 11y ago
      > I do not like broccoli. And I haven't liked it since I was a little kid and my mother made me eat it. And I'm President of the United States and I'm not going to eat any more broccoli. Some people just don't like broccoli. You can force them to eat it, but they'll end up resenting you.
    - marcosdumay 11y ago
      What's wrong in doing things the way you are comfortable doing?
    - sheepmullet 11y ago
      It leads to lots of brittle and highly coupled tests? It always focuses on the next immediate task which leads to going down a lot of dead ends, and a lot of local optimums that need to be refactored out? The key benefit is that it helps you focus, even when tired or stressed. You get dozens of small wins/celebrations every hour which is great for your motivation. It also ensures you actually write tests (again handy with tight deadlines and high stress situations). Does that make it worthwhile? Sometimes. I did a TDD exclusively when I had young kids and it was a great help with my focus. I'd recommend it to new parents, people with sleeping disorders, people in high stress work places, etc.
HeyLaughingBoy 11y ago
No TDD != lack of unit testing. I am a big believer in unit tests, but don't like TDD much. I think it fosters the belief that you can test quality into a product. Testing should be a verification that the rest of your process has resulted in a high quality product. It shouldn't be the means of getting quality into the product.
- jander 11y ago
  Hmm sorry, I've never heard of TDD guaranteeing quality of a product. It _might_ mean you've delivered what's been asked of you (along with acceptance testing) but quality? Far from it. And if you're unit testing _after_ the fact, then you're just asking for trouble.
  - anthonybsd 11y ago
    I'm in the same boat. TDD might be suited for some narrow cases of development workflows. However, it doesn't do too well for others, and completely poorly for a vast category of things. Overall, if your Sprint defines good unit test coverage as criterion for "Dev Complete" it's more than sufficient.
    - crdoconnor 11y ago
      >I'm in the same boat. TDD might be suited for some narrow cases of development workflows. However, it doesn't do too well for others, and completely poorly for a vast category of things. I find where it works poorly it tends to just mean you have poor testing tools at your disposal. Plus, people have a tendency to test things at far too low a level.
      - jander 11y ago
        > Plus, people have a tendency to test things at far too low a level. That's usually what drives people away from TDD. A very good approach for this is described at this article by Dave Hunt: https://medium.com/@davidihunt/tdd-and-complexity-1bbd5ca51ee7 https://medium.com/@davidihunt/tdd-and-complexity-1bbd5ca51e...
diegoperini 11y ago
I believe TDD is not the only methodology where unit tests are allowed. As far as I know, TDD suggests that the software is planned and driven by many failing test that are coded initially. A cautious developer may prefer building a feature on top of a failed (later to be satisfied) test but we worry that documenting the target product with all the necessary server and client tests may consume too much time initially. Some features that are likely to be postponed for later releases should not allocate our precious time and in the beginning, we may lack necessary wisdom to foresee it. The other worry is that TDD in its most basic form is still a coding framework which may leave less freedom for the developer to express his/her preferred productive approach. We prefer to apply a framework on how we communicate, keep track of changes and measure our performance. The rest is left for the developer to experiment and find the most effective style for herself.
- popra 11y ago
  You don't have to write the unit tests up front for the full app - in fact doing that could be considered going against agility. The way TDD is usually done is that the developer writes the tests for the feature she's currently working on, before actually working on the feature.

"TDD is not an option" and yet,at the same breath ".. unit tested.."? I'm puzzled, care to elaborate the logic behind your statements?

by jander 11y ago

"TDD is not an option" and yet,at the same breath ".. unit tested.."? I'm puzzled, care to elaborate the logic behind your statements?

mlpinit 11y ago

my understanding: instead of driving by writing tests first, they first write the implementation and then they test.

philbarr 11y ago
And definitely if the team agree they don't like TDD, don't force it onto them. In this situation at least.
- jander 11y ago
  Assuming they have a solid and reasonable argument against it and not just hand-waving and throwing toys out of the pram :-) . In which case, if they do, I would love to see it.
  - jakubp 11y ago
    The burden of proof usually lies on the person suggesting a change to an existing process. What arguments would you give to try to convince someone to do TDD? Because arguments against can be really simple and reasonable: "it's a risky change that will slow us down without obvious upsides", "we don't like to change, it's effortful, and stressful", "we don't have the skills to do it" etc. And that can be told of ANY change of any process/routine! So what would you say to a team of developers if you wanted to persuade them to do TDD? (or to a manager who has influence on them)
    - crdoconnor 11y ago
      >The burden of proof usually lies on the person suggesting a change to an existing process. What arguments would you give to try to convince someone to do TDD? Arguments don't work. You need to build the tools that let your developers actually write sensible tests (i.e. tests which mimic user stories). Once the tools are there the process becomes fairly natural and the upsides become obvious. Some people call this BDD. It doesn't really matter what it's called, but it's generally a faster and less risky approach to programming.
  - alextgordon 11y ago
    > I do not like broccoli. And I haven't liked it since I was a little kid and my mother made me eat it. And I'm President of the United States and I'm not going to eat any more broccoli. Some people just don't like broccoli. You can force them to eat it, but they'll end up resenting you.
  - marcosdumay 11y ago
    What's wrong in doing things the way you are comfortable doing?
  - sheepmullet 11y ago
    It leads to lots of brittle and highly coupled tests? It always focuses on the next immediate task which leads to going down a lot of dead ends, and a lot of local optimums that need to be refactored out? The key benefit is that it helps you focus, even when tired or stressed. You get dozens of small wins/celebrations every hour which is great for your motivation. It also ensures you actually write tests (again handy with tight deadlines and high stress situations). Does that make it worthwhile? Sometimes. I did a TDD exclusively when I had young kids and it was a great help with my focus. I'd recommend it to new parents, people with sleeping disorders, people in high stress work places, etc.

HeyLaughingBoy 11y ago

No TDD != lack of unit testing. I am a big believer in unit tests, but don't like TDD much. I think it fosters the belief that you can test quality into a product. Testing should be a verification that the rest of your process has resulted in a high quality product. It shouldn't be the means of getting quality into the product.

jander 11y ago
Hmm sorry, I've never heard of TDD guaranteeing quality of a product. It _might_ mean you've delivered what's been asked of you (along with acceptance testing) but quality? Far from it. And if you're unit testing _after_ the fact, then you're just asking for trouble.
- anthonybsd 11y ago
  I'm in the same boat. TDD might be suited for some narrow cases of development workflows. However, it doesn't do too well for others, and completely poorly for a vast category of things. Overall, if your Sprint defines good unit test coverage as criterion for "Dev Complete" it's more than sufficient.
  - crdoconnor 11y ago
    >I'm in the same boat. TDD might be suited for some narrow cases of development workflows. However, it doesn't do too well for others, and completely poorly for a vast category of things. I find where it works poorly it tends to just mean you have poor testing tools at your disposal. Plus, people have a tendency to test things at far too low a level.
    - jander 11y ago
      > Plus, people have a tendency to test things at far too low a level. That's usually what drives people away from TDD. A very good approach for this is described at this article by Dave Hunt: https://medium.com/@davidihunt/tdd-and-complexity-1bbd5ca51ee7 https://medium.com/@davidihunt/tdd-and-complexity-1bbd5ca51e...

diegoperini 11y ago

I believe TDD is not the only methodology where unit tests are allowed. As far as I know, TDD suggests that the software is planned and driven by many failing test that are coded initially. A cautious developer may prefer building a feature on top of a failed (later to be satisfied) test but we worry that documenting the target product with all the necessary server and client tests may consume too much time initially. Some features that are likely to be postponed for later releases should not allocate our precious time and in the beginning, we may lack necessary wisdom to foresee it. The other worry is that TDD in its most basic form is still a coding framework which may leave less freedom for the developer to express his/her preferred productive approach. We prefer to apply a framework on how we communicate, keep track of changes and measure our performance. The rest is left for the developer to experiment and find the most effective style for herself.

popra 11y ago
You don't have to write the unit tests up front for the full app - in fact doing that could be considered going against agility. The way TDD is usually done is that the developer writes the tests for the feature she's currently working on, before actually working on the feature.