When we shared this on Twitter, we had lots of discussions. Clearly a hot topic. What do you think?
Here are some of the discussions
It’s been around a long time. Depressingly, at #DeliveryConf last week, some leading practitioners said they see less and less of it, even though it is shown to reduce bugs by 70% (more, in my experience). It’s hard to learn, ppl won’t make the big investment, despite ROI.
TDD is not agile.
It delays the, inspect and adapt, feedback loop we strive for. Also our code visible, transparent, to all so there is already enough possibility to check the code.
well, I’m not qualified to defend TDD, though having worked on teams who practiced it well, I can attest to how it helped build a quality software product. There are studies that people like @jezhumble &@davefarley77 pointed to at #DeliveryConf, but those don’t sway people!!
IMO it is a matter of helping highlight another perspective. Is time for a story to be off your plate important? Or time until value is seen? If we track cycle time as idea->prod (rather than just “dev-ing”) & we track rework it changes whether you think TDD even slows you down
TDD is not BDD. Especially for API development, TDD is a really good approach. It is very old news but still very useful.
BDD has been described by Dan North innorder to remain the benefits about having conversion between dev, test, and product owner. The goal is to define nominal use cases and unthinking use cases. BDD is human. TDD is design
Most certainly not old news. I did TDD today. Also, people are still struggle in adopting it so TDD consulting services are still hot like it was discovered yesterday.
Absolutely relevant. Can tests be written after? Yes. In my experience this leads to missing test coverage while your test coverage is near or at 100%. TDD is good practice because it changes how you implement. It gets you thinking about correct behavior not current. Unit testing is not intuitive. Most devs kind of suck at it. That’s fine because it takes practice.