5 ms·

TBH, I don't know anyone who does TDD. I only know a few handfuls of developers, but so far the only people I've briefly met that do TDD were ones selling it; t

TBH, I don't know anyone who does TDD. I only know a few handfuls of developers, but so far the only people I've briefly met that do TDD were ones selling it; the consulting company that came into the company I worked for. This consulting company tried to "teach" us TDD at the same time as I think they were learning it. Not a single developer out of the ~40 on our teams bought into it, because in almost all cases the code for a given example (during these 90 minute seminars) was always more confusing and obfuscated, and the unit tests didn't truly match the business case, because TDD is a bit like waterfall, in the sense that you're assuming you know what the code needs to do before you write it (how many times, especially for a large project, does your code change before you finish and are ready to write tests?). After the 3 months of consulting, they left us and we continued on writing code and unit tests (in that order) just as we had before. I think that TDD changes your code for the worse, except in very small, controlled cases. For e.g., a large web app, I think it just creates a mess. If you think of all unit tests as regression tests, you'll have a good time.

ep103 10y ago
I somewhat agree. I think everyone should have to do TDD at least once, on a reasonably sized project. Thereafter, I'd trust them to pick and choose the important tests to write. TDD tends to result in a lot of unnecessary testing, but I've seen too many devs with no idea what should be tested, or how to write a good test, or how to write non-fragile tests, etc. Note, the above is for things like web applications. For, say, hospital or billing code, TDD makes perfect sense.
BenoitP 10y ago
> TDD is a bit like waterfall, in the sense that you're assuming you know what the code needs to do before you write it Very true; but there are cases where you actually have that knowledge. If you are asked to port some application to another framework or language, and have tests, I'd highly recommend you use them. I have been refactoring an ETL pipeline (to offer extensible, more flexible behavior) that sort of grew out of interns applying ad hoc transient business rules. No tests were present but I had a quite large coverage over past inputs that were yielding a correct output. I'd say code size shrank about 70%.
- mangeletti 10y ago
  > ... and have tests, I'd highly recommend you use them... Absolutely, but that's not TDD. The old tests (presumably) were written as regression tests, and code changes must comply to the (hence) regression tests' expectations. That's perfectly reasonable, and I think that's most tested software projects operate.
Jtsummers 10y ago
I'm not sure I understand your perspective. If you have a specification (shouldn't a web app have a specification? Admittedly, I've never developed one, my world is embedded), then you have something to write your tests too. While we don't use unit tests in my office, we do use comprehensive testing and a (mostly) TDD style (accidentally or coincidentally, our process has operated in roughly the same way for 30 years, mostly improvements to speed by way of automation). We have a spec, we need our device to respond to message X with message Y after time delay T (or within time window [T1,T2]). We've constructed tests which verify these requirements. We write software that passes (or not) these tests. When we fail, we isolate the cause of the failure (sometimes we're dealing with several levels of hardware, not all under our control). Where the fault is ours, we fix it. Where it's not, we report it and wait a week for a fix (and test other things in the interim). This message protocol is our API, the thing we need to test. If it were a web app, you'd have some set of URLs and GET/PUT requests that should cause some desired and measurable behavior.
- mangeletti 10y ago
  > If you have a specification... A specification doesn't translate directly into code. Otherwise, developers wouldn't have jobs. A specification is interpreted by developers, then reinterpreted by other developers, managers, etc., then updated, etc.
  - Jtsummers 10y ago
    You can create your own specification from the stakeholders' requirements. If you can't create a specification, how do you define what you're programming in order to develop towards some goal?
    - mangeletti 10y ago
      Can you paste an example specification for a small program? I use a whiteboard (or paper), as do many others, to diagram things out, as a means to put a program's abstract form into my brain. That whiteboard doesn't contain the entire program.
k__ 10y ago
I did a new "production" project where I did full TDD. Ended up with about 200 tests. As things go, specs changed and part of this application had to be rewritten. Most of the tests started to fail, not because the code was wrong, but because they tested for different spec. So I needed to rewrite all those unit tests again. Sure, I catched "some" refactoring bugs, but most failed tests weren't bugs, just tests that became wrong. This made me question the whole TDD approach in production.
- deleted 10y ago
  [deleted]

ep103 10y ago

I somewhat agree. I think everyone should have to do TDD at least once, on a reasonably sized project. Thereafter, I'd trust them to pick and choose the important tests to write. TDD tends to result in a lot of unnecessary testing, but I've seen too many devs with no idea what should be tested, or how to write a good test, or how to write non-fragile tests, etc. Note, the above is for things like web applications. For, say, hospital or billing code, TDD makes perfect sense.

BenoitP 10y ago

> TDD is a bit like waterfall, in the sense that you're assuming you know what the code needs to do before you write it Very true; but there are cases where you actually have that knowledge. If you are asked to port some application to another framework or language, and have tests, I'd highly recommend you use them. I have been refactoring an ETL pipeline (to offer extensible, more flexible behavior) that sort of grew out of interns applying ad hoc transient business rules. No tests were present but I had a quite large coverage over past inputs that were yielding a correct output. I'd say code size shrank about 70%.

mangeletti 10y ago
> ... and have tests, I'd highly recommend you use them... Absolutely, but that's not TDD. The old tests (presumably) were written as regression tests, and code changes must comply to the (hence) regression tests' expectations. That's perfectly reasonable, and I think that's most tested software projects operate.

Jtsummers 10y ago

I'm not sure I understand your perspective. If you have a specification (shouldn't a web app have a specification? Admittedly, I've never developed one, my world is embedded), then you have something to write your tests too. While we don't use unit tests in my office, we do use comprehensive testing and a (mostly) TDD style (accidentally or coincidentally, our process has operated in roughly the same way for 30 years, mostly improvements to speed by way of automation). We have a spec, we need our device to respond to message X with message Y after time delay T (or within time window [T1,T2]). We've constructed tests which verify these requirements. We write software that passes (or not) these tests. When we fail, we isolate the cause of the failure (sometimes we're dealing with several levels of hardware, not all under our control). Where the fault is ours, we fix it. Where it's not, we report it and wait a week for a fix (and test other things in the interim). This message protocol is our API, the thing we need to test. If it were a web app, you'd have some set of URLs and GET/PUT requests that should cause some desired and measurable behavior.

mangeletti 10y ago
> If you have a specification... A specification doesn't translate directly into code. Otherwise, developers wouldn't have jobs. A specification is interpreted by developers, then reinterpreted by other developers, managers, etc., then updated, etc.
- Jtsummers 10y ago
  You can create your own specification from the stakeholders' requirements. If you can't create a specification, how do you define what you're programming in order to develop towards some goal?
  - mangeletti 10y ago
    Can you paste an example specification for a small program? I use a whiteboard (or paper), as do many others, to diagram things out, as a means to put a program's abstract form into my brain. That whiteboard doesn't contain the entire program.

k__ 10y ago

I did a new "production" project where I did full TDD. Ended up with about 200 tests. As things go, specs changed and part of this application had to be rewritten. Most of the tests started to fail, not because the code was wrong, but because they tested for different spec. So I needed to rewrite all those unit tests again. Sure, I catched "some" refactoring bugs, but most failed tests weren't bugs, just tests that became wrong. This made me question the whole TDD approach in production.

deleted 10y ago
[deleted]