5 ms·

That should itself be rather telling. TDD is extremely well known, in my experience. I bet if I stuck a microphone under the nose of random passersby at any dev

That should itself be rather telling. TDD is extremely well known, in my experience. I bet if I stuck a microphone under the nose of random passersby at any development convention [1], 90%+ will be able to tell me what 'TDD' is short for, and even if they don't, they'll have heard of the concept at least. Hell, I bet most would tell me they 'aspire to do it'. And yet, more or less nobody does. So either it is next to impossible to begin doing it (seems like a bizarre conclusion), or, perhaps more likely, nobody wants to do it, and the few dev teams that do manage to do this have not managed to turn that into a competitive advantage. Which makes the value of TDD rather questionable based on simple evidence. To explain this observed behaviour that TDD is clearly not a competitive advantage[2], I can name a million pet theories. But without going into any of those, the sheer fact that it's __this__ rare in practice says a lot, no? [1] I mostly go to java related ones, maybe it's less well known amongst other communities. [2] What other explanation is there? Clearly not 'ah, but, TDD is brand new and you have to give it some time for teams to get familiar with it, and for the concept to percolate through, maybe wait for tooling support to catch up' - TDD's quite an old concept!

3pt14159 6y ago
Well I do TDD around 85% of the time and I'm doing pretty well financially as a dev. Sometimes it isn't possible to do TDD, like when I'm iterating on a data science algorithm or exploring data and relationships before settling on a final approach. But you're right, most devs I know don't do it, though I've noticed the ones that do generally make more.
- guscost 6y ago
  > I’ve noticed the ones that do generally make more. The market may be rewarding the TDD skill, it makes sense. But consider that causality makes sense the other way around too. Anyone with the patience, eye for detail, and organizational skills demanded by TDD could be just an above-average programmer. Personally I like a “don’t forget the tests” approach for larger units of business logic, but I’m against exhaustive micro-test suites that just turn into bespoke, buggy, and useless-at-compile-time type systems.
  - RandoHolmes 6y ago
    oh please, this is the programmer version of "if you're reading this blog you're already in the top X% of <insert industry here>".
    - guscost 6y ago
      The top 50% are capable of actually doing TDD? I don’t see why that’s impossible, especially if they are the ones implementing it, not just pushing tickets along within it. And I don’t really follow TDD practices myself, so this would say nothing about me.
- geebee 6y ago
  Interesting. You're defending and advocating for TDD, and you use it 85% of the time. I've used TDD as well, and I notice it tends to work very well for certain types of workflows. Otherwise, I write a little code, test a little code, back and forth. Almost everyone does this (you write a method, you tend to write a little test to see if it does what it's supposed to). To get high test coverage, you just save those little tests that you naturally write anyway. It's a good way to get high testing coverage without imposing an odd-feeling methodology into what should be a creative workflow. When the big "TDD is dead" debate hit the scene, I felt that DHH and the detractors won that debate big time - even though I use TDD and consider it to be a valuable tool. Why would I think this - after all, if I like TDD and often employ it, why would I agree that the people who claim it is "dead" have won? Probably because the debate had become relatively extreme: https://blog.cleancoder.com/uncle-bob/2014/05/02/ProfessionalismAndTDD.html https://blog.cleancoder.com/uncle-bob/2014/05/02/Professiona... "If I am right… If TDD is as significant to software as hand-washing was to medicine and is instrumental in pulling us back from the brink of that looming catastrophe, then Kent Beck will be hailed a hero, and TDD will carry the full weight of professionalism. After that, those who refuse to practice TDD will be excused from the ranks of professional programmers. It would not surprise me if, one day, TDD had the force of law behind it." Whoah! And keep in mind, people were acting on this. I read a blog (sorry no cite) from a highly regarded developer who worked as a contractor to restructure software dev teams, and he came flat out and said that if people don't adopt TDD, they won't be employed for much longer wherever he works. I got the feeling that even questioning it would be considered grounds for "no hire". That mentality is what I think is "dead" - and this is evidenced in the fact that you and I (who do quite a bit of TDD) acknowledge that it is not something we always do and that it isn't always possible or desirable. I got in wicked arguments about this at work, and I'm almost certain I was dropped from consideration for jobs during interviews where I argued the now more moderate position which, ironically, makes me one of TDD's defenders in 2020!.
  - 3pt14159 6y ago
    Absolutely, but I still prefer the interfaces that come out of doing proper TDD. I minimize the use of mocks and try to pull in as much of the infrastructure as possible. I'm pragmatic though. I'll use fakeredis in tests instead of actual redis so the tests can run concurrently without quirks. It's hard to communicate as a developer at times. We're all learning different things at different times and taking things to an extreme can cause bad outcomes for the rest of the team. One of the reasons I try to be accurate during online discussions. "I do TDD 85% of the time" is a better thing to add to the conversation than "I do TDD" since it gives people the idea of nuance in software development methods.
- sidlls 6y ago
  Careful with this reasoning. It could be that those who insist on TDD are simply the loudest or most confident or whatever, and therefore are more often in a position to advance themselves. "Their stuff works better" isn't necessarily the link between "TDD" and "make more".
DigitalSea 6y ago
Exactly. I think most experienced developers know about TDD, maybe they have even tried it on a personal project. But, selling it to a company that have commitments to investors, paying customers and an executive team who might not all have technical backgrounds makes TDD a hard sell. How do you explain to people who don't get it that things will take longer? One of the biggest problems with TDD is that it kind of relies on having clearly defined specifications. I don't know about you or other people here, but I've worked in a lot of places (many even called themselves Agile) where the work was not properly scoped at all. If you start doing TDD and the scope isn't clear, the goal posts keep on moving and things just perpetually take longer. I think it's all about cost in the end. It's cheaper for companies to ship buggy code and then iteratively patch the bugs. Unless they're massive showstopper bugs (which normal tests should be catching anyway), it probably still comparatively works out cheaper to fix bugs as you find them.
- catwind7 6y ago
  > One of the biggest problems with TDD is that it kind of relies on having clearly defined specifications That's very true. I think it's an easier sell when you have a relatively stable set of specifications (accounting software core logic) where the rate of change is low but the cost of regressions is high. But I think you can tackle the same problem space with good unit tests instead of enforcing a test-first mindset. In situations where work is vague, spending more upfront time thinking about architecture is much more useful (design docs?) imo. Having a set of units for a crappy, entangled system is pretty costly.
- MockObject 6y ago
  > I don't know about you or other people here, but I've worked in a lot of places (many even called themselves Agile) where the work was not properly scoped at all. I can see this argument for large-scoped scenario based integration tests, definitely. But TDD unit testing operates on a much smaller scale, that of a single patch, or a Jira ticket.
- hn_check 6y ago
  "But, selling it to a company that have commitments to investors, paying customers and an executive team who might not all have technical backgrounds makes TDD a hard sell" It's an incredibly easy sale. The whole basis of TDD is that it's an approach that makes your development efforts faster, with higher quality. A million graphics of the amount of time that development spends fixing errors are what sold TDD to the masses. The theory of TDD is exactly what sells to the suits and the money counters. The theory doesn't mesh with reality, though, and it's that engagement with the enemy (reality) where TDD falls down. As an aside, in my own career I've seldom been able to incorporate TDD because each project has been novel enough that trying to define tests up front was just not possible. Yes, if I was implementing the re-invent the wheel "sum two numbers" type example, it's trivial. But most of the time it's a vague API for a vague need on an uncertain technical foundation, and until the clay has taken form we really weren't sure what we were dealing with.
SkyBelow 6y ago
>So either it is next to impossible to begin doing it (seems like a bizarre conclusion), or, perhaps more likely, nobody wants to do it, and the few dev teams that do manage to do this have not managed to turn that into a competitive advantage. Which makes the value of TDD rather questionable based on simple evidence. Or the competitive advantages it offers do not align with the competitive advantages our society currently selects for. These days it seems that short term profits are the primary factor selected for and that users tend to go with the first to market until it has a significantly worse experience. >But without going into any of those, the sheer fact that it's __this__ rare in practice says a lot, no? It's a bit like how good security is a rare practice, as good enough security is much cheaper and the cost of security incidents is generally not as large as they should be (for example, data breaches have most of their costs pushed onto the victims of the data being leaked and not the collecting company that was breached).
gwbas1c 6y ago
> To explain this observed behaviour that TDD is clearly not a competitive advantage[2], I can name a million pet theories. But without going into any of those, the sheer fact that it's __this__ rare in practice says a lot, no? Short answer: TDD is hard Long answer: It takes a very experienced engineer to start and layout a piece of software so that it's easy to write and maintain tests. IMO, this is one of the advantages of server-side rendered web applications; it's much easier to write a test that verifies HTML than a test that verifies the state of a Windows / Mac application; or even the state of the DOM in a rich in-browser application. But, continuing on that train of thought: It's much easier, as a developer, to write a test that tests an API, (either programmatic API or web service) as a unit than a giant monolith.
- RandoHolmes 6y ago
  The only circumstances in which I can see writing tests against HTML directly is if you're doing a move or a migration. I did exactly this for a hosting company back when Windows Server 2003 was getting EOL'd. They setup on 2012, migrated the sites over, and then my script would pull from both versions and see how much variation there was. Even then it was mostly just a diff. Otherwise that's the equivalent of testing implementation details.
  - gwbas1c 6y ago
    Write a test that: 1: Stick an entity in the database 2: Try to get the page for the entity without logging in. Verify the error page 3: Log in as someone who doesn't have the entity. Try to get the page for the entity. Verify the error page 4: Log in as someone who can get the entity. Verify some basics of the page contents Write a test that: 1: Posts the contents of the form without logging in. Verify the error. ... 4: Log in as someone who can post the form. Post the contents of the form. Verify the contents are in the database. Tests like above meet the higher-level post's definition of a "unit test" and are rather easy to write. You don't even have to be in the same language as application. They're simple enough that developers can write them as part of their workflow, and simple enough that developers can run them to ensure no regressions. Trying to do something like that with a thick UI application is much, much harder. Possible, but not easy.
cactus2093 6y ago
One analogy that has come to mind for me is TDD is like eating a whole food diet with a ton of vegetables and no processed foods. When you're doing it, you feel great, or at least you convince yourself that you feel great because you know you're supposed to. But ultimately it's hard to keep it up. It gets tedious, it requires a lot of willpower, and the benefits are a little too abstract or far removed. At the end of the day, most people will be just as healthy with a more moderate approach. Just eat some vegetables, not too much sugar, and keep a reasonable limit on total calories. In the programming analogy - just write some tests for important functionality, and be careful that the tests you write are actually working, but you don't need to be fanatical about writing the tests before the functionality or having 100% coverage. And then as with diet, it's also possible that if you're aiming for the moderate approach you end up slipping too much to the other extreme and writing almost no tests. For some people a structured diet is necessary to keep them on track, and I suspect for some people TDD can be a more effective tool than it is for others if their default coding style tends toward more sloppy/unstructured.
marcosdumay 6y ago
> So either it is next to impossible to begin doing it (seems like a bizarre conclusion), or, perhaps more likely, nobody wants to do it Or it is an incredibly good procedure for a tiny minority of the projects, but sucks for the vast majority of them.
rv-de 6y ago
Test are like Haskell, it seems.

3pt14159 6y ago

Well I do TDD around 85% of the time and I'm doing pretty well financially as a dev. Sometimes it isn't possible to do TDD, like when I'm iterating on a data science algorithm or exploring data and relationships before settling on a final approach. But you're right, most devs I know don't do it, though I've noticed the ones that do generally make more.

guscost 6y ago
> I’ve noticed the ones that do generally make more. The market may be rewarding the TDD skill, it makes sense. But consider that causality makes sense the other way around too. Anyone with the patience, eye for detail, and organizational skills demanded by TDD could be just an above-average programmer. Personally I like a “don’t forget the tests” approach for larger units of business logic, but I’m against exhaustive micro-test suites that just turn into bespoke, buggy, and useless-at-compile-time type systems.
- RandoHolmes 6y ago
  oh please, this is the programmer version of "if you're reading this blog you're already in the top X% of <insert industry here>".
  - guscost 6y ago
    The top 50% are capable of actually doing TDD? I don’t see why that’s impossible, especially if they are the ones implementing it, not just pushing tickets along within it. And I don’t really follow TDD practices myself, so this would say nothing about me.
geebee 6y ago
Interesting. You're defending and advocating for TDD, and you use it 85% of the time. I've used TDD as well, and I notice it tends to work very well for certain types of workflows. Otherwise, I write a little code, test a little code, back and forth. Almost everyone does this (you write a method, you tend to write a little test to see if it does what it's supposed to). To get high test coverage, you just save those little tests that you naturally write anyway. It's a good way to get high testing coverage without imposing an odd-feeling methodology into what should be a creative workflow. When the big "TDD is dead" debate hit the scene, I felt that DHH and the detractors won that debate big time - even though I use TDD and consider it to be a valuable tool. Why would I think this - after all, if I like TDD and often employ it, why would I agree that the people who claim it is "dead" have won? Probably because the debate had become relatively extreme: https://blog.cleancoder.com/uncle-bob/2014/05/02/ProfessionalismAndTDD.html https://blog.cleancoder.com/uncle-bob/2014/05/02/Professiona... "If I am right… If TDD is as significant to software as hand-washing was to medicine and is instrumental in pulling us back from the brink of that looming catastrophe, then Kent Beck will be hailed a hero, and TDD will carry the full weight of professionalism. After that, those who refuse to practice TDD will be excused from the ranks of professional programmers. It would not surprise me if, one day, TDD had the force of law behind it." Whoah! And keep in mind, people were acting on this. I read a blog (sorry no cite) from a highly regarded developer who worked as a contractor to restructure software dev teams, and he came flat out and said that if people don't adopt TDD, they won't be employed for much longer wherever he works. I got the feeling that even questioning it would be considered grounds for "no hire". That mentality is what I think is "dead" - and this is evidenced in the fact that you and I (who do quite a bit of TDD) acknowledge that it is not something we always do and that it isn't always possible or desirable. I got in wicked arguments about this at work, and I'm almost certain I was dropped from consideration for jobs during interviews where I argued the now more moderate position which, ironically, makes me one of TDD's defenders in 2020!.
- 3pt14159 6y ago
  Absolutely, but I still prefer the interfaces that come out of doing proper TDD. I minimize the use of mocks and try to pull in as much of the infrastructure as possible. I'm pragmatic though. I'll use fakeredis in tests instead of actual redis so the tests can run concurrently without quirks. It's hard to communicate as a developer at times. We're all learning different things at different times and taking things to an extreme can cause bad outcomes for the rest of the team. One of the reasons I try to be accurate during online discussions. "I do TDD 85% of the time" is a better thing to add to the conversation than "I do TDD" since it gives people the idea of nuance in software development methods.
sidlls 6y ago
Careful with this reasoning. It could be that those who insist on TDD are simply the loudest or most confident or whatever, and therefore are more often in a position to advance themselves. "Their stuff works better" isn't necessarily the link between "TDD" and "make more".

DigitalSea 6y ago

Exactly. I think most experienced developers know about TDD, maybe they have even tried it on a personal project. But, selling it to a company that have commitments to investors, paying customers and an executive team who might not all have technical backgrounds makes TDD a hard sell. How do you explain to people who don't get it that things will take longer? One of the biggest problems with TDD is that it kind of relies on having clearly defined specifications. I don't know about you or other people here, but I've worked in a lot of places (many even called themselves Agile) where the work was not properly scoped at all. If you start doing TDD and the scope isn't clear, the goal posts keep on moving and things just perpetually take longer. I think it's all about cost in the end. It's cheaper for companies to ship buggy code and then iteratively patch the bugs. Unless they're massive showstopper bugs (which normal tests should be catching anyway), it probably still comparatively works out cheaper to fix bugs as you find them.

catwind7 6y ago
> One of the biggest problems with TDD is that it kind of relies on having clearly defined specifications That's very true. I think it's an easier sell when you have a relatively stable set of specifications (accounting software core logic) where the rate of change is low but the cost of regressions is high. But I think you can tackle the same problem space with good unit tests instead of enforcing a test-first mindset. In situations where work is vague, spending more upfront time thinking about architecture is much more useful (design docs?) imo. Having a set of units for a crappy, entangled system is pretty costly.
MockObject 6y ago
> I don't know about you or other people here, but I've worked in a lot of places (many even called themselves Agile) where the work was not properly scoped at all. I can see this argument for large-scoped scenario based integration tests, definitely. But TDD unit testing operates on a much smaller scale, that of a single patch, or a Jira ticket.
hn_check 6y ago
"But, selling it to a company that have commitments to investors, paying customers and an executive team who might not all have technical backgrounds makes TDD a hard sell" It's an incredibly easy sale. The whole basis of TDD is that it's an approach that makes your development efforts faster, with higher quality. A million graphics of the amount of time that development spends fixing errors are what sold TDD to the masses. The theory of TDD is exactly what sells to the suits and the money counters. The theory doesn't mesh with reality, though, and it's that engagement with the enemy (reality) where TDD falls down. As an aside, in my own career I've seldom been able to incorporate TDD because each project has been novel enough that trying to define tests up front was just not possible. Yes, if I was implementing the re-invent the wheel "sum two numbers" type example, it's trivial. But most of the time it's a vague API for a vague need on an uncertain technical foundation, and until the clay has taken form we really weren't sure what we were dealing with.

SkyBelow 6y ago

>So either it is next to impossible to begin doing it (seems like a bizarre conclusion), or, perhaps more likely, nobody wants to do it, and the few dev teams that do manage to do this have not managed to turn that into a competitive advantage. Which makes the value of TDD rather questionable based on simple evidence. Or the competitive advantages it offers do not align with the competitive advantages our society currently selects for. These days it seems that short term profits are the primary factor selected for and that users tend to go with the first to market until it has a significantly worse experience. >But without going into any of those, the sheer fact that it's __this__ rare in practice says a lot, no? It's a bit like how good security is a rare practice, as good enough security is much cheaper and the cost of security incidents is generally not as large as they should be (for example, data breaches have most of their costs pushed onto the victims of the data being leaked and not the collecting company that was breached).

gwbas1c 6y ago

> To explain this observed behaviour that TDD is clearly not a competitive advantage[2], I can name a million pet theories. But without going into any of those, the sheer fact that it's __this__ rare in practice says a lot, no? Short answer: TDD is hard Long answer: It takes a very experienced engineer to start and layout a piece of software so that it's easy to write and maintain tests. IMO, this is one of the advantages of server-side rendered web applications; it's much easier to write a test that verifies HTML than a test that verifies the state of a Windows / Mac application; or even the state of the DOM in a rich in-browser application. But, continuing on that train of thought: It's much easier, as a developer, to write a test that tests an API, (either programmatic API or web service) as a unit than a giant monolith.

RandoHolmes 6y ago
The only circumstances in which I can see writing tests against HTML directly is if you're doing a move or a migration. I did exactly this for a hosting company back when Windows Server 2003 was getting EOL'd. They setup on 2012, migrated the sites over, and then my script would pull from both versions and see how much variation there was. Even then it was mostly just a diff. Otherwise that's the equivalent of testing implementation details.
- gwbas1c 6y ago
  Write a test that: 1: Stick an entity in the database 2: Try to get the page for the entity without logging in. Verify the error page 3: Log in as someone who doesn't have the entity. Try to get the page for the entity. Verify the error page 4: Log in as someone who can get the entity. Verify some basics of the page contents Write a test that: 1: Posts the contents of the form without logging in. Verify the error. ... 4: Log in as someone who can post the form. Post the contents of the form. Verify the contents are in the database. Tests like above meet the higher-level post's definition of a "unit test" and are rather easy to write. You don't even have to be in the same language as application. They're simple enough that developers can write them as part of their workflow, and simple enough that developers can run them to ensure no regressions. Trying to do something like that with a thick UI application is much, much harder. Possible, but not easy.

cactus2093 6y ago

One analogy that has come to mind for me is TDD is like eating a whole food diet with a ton of vegetables and no processed foods. When you're doing it, you feel great, or at least you convince yourself that you feel great because you know you're supposed to. But ultimately it's hard to keep it up. It gets tedious, it requires a lot of willpower, and the benefits are a little too abstract or far removed. At the end of the day, most people will be just as healthy with a more moderate approach. Just eat some vegetables, not too much sugar, and keep a reasonable limit on total calories. In the programming analogy - just write some tests for important functionality, and be careful that the tests you write are actually working, but you don't need to be fanatical about writing the tests before the functionality or having 100% coverage. And then as with diet, it's also possible that if you're aiming for the moderate approach you end up slipping too much to the other extreme and writing almost no tests. For some people a structured diet is necessary to keep them on track, and I suspect for some people TDD can be a more effective tool than it is for others if their default coding style tends toward more sloppy/unstructured.

marcosdumay 6y ago

> So either it is next to impossible to begin doing it (seems like a bizarre conclusion), or, perhaps more likely, nobody wants to do it Or it is an incredibly good procedure for a tiny minority of the projects, but sucks for the vast majority of them.

rv-de 6y ago

Test are like Haskell, it seems.