Skip to content
0:00 / 0:00

#tdd#mocking#test-drivendevelopment

Is TDD dead?

Thoughtworks

51K subscribers • 2 videos on Hallway

YouTube
  • Recommended by 2 people: 1 on Hacker News and 1 on Lobsters.
  • Presented by Martin Fowler, Kent Beck, and David Heinemeier Hansson
  • An opinion. It argues one side of a question engineers disagree on.

Intermediate. Assumes working knowledge.

192K views12 years ago2 recommendations

Tools and practiceSoftware designTestingSoftware architecture

Martin Fowler, Kent Beck, and David Heinemeier Hansson debate the tradeoffs, benefits, and design impacts of test-driven development.

"TDD as One True Way" versus "TDD as devil-spawned tempter" is not a productive contrast. Most of us have similar goals for development: confidence, impact, challenge, belonging. Test-driven development is one path toward these goals, but there are many other paths. This conversation in six parts explores tradeoffs in development, places TDD in those tradeoffs, and gives you perspective with which you can decide for yourself how you want to program. Speakers: Martin Fowler Kent Beck David Heinemeier Hansson (DHH)

Why it's here

2 people recommend this

What people say. Recommended as a nuanced debate on when to use test-driven development and how to approach mocking.

Moments people linked to

ollysbon Hacker News • Recommends

On “Ask HN: How do I start with test driven development?”

I can't recommend the discussion between Kent Beck, David Hansson and Martin Fowler enough. They look at how and where it should be used and in particular discuss their approach to mocking which I feel is an often misunderstood tool. Part 1 - link to this video Part 2 - link Part 3 - link Part 4/5 - link

szalanskyon Lobsters • Recommends

Is TDD dead? - YouTube Discussion between DHH, Martin Fowler and Kent Beck about TDD principles and its role in the world of software development techniques. This video is a followup of DHH's blog posts: http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html http://david.heinemeierhansson.com/2014/test-induced-design-damage.html http://david.heinemeierhansson.com/2014/slow-database-test-fallacy.html

ChrisGaudreauon Hacker News • Mentions

On “The DHH Problem”

> Because DHH is just one person. And he only has DHH's experiences. Yep. Uncle Bob is one person, too. tl;dr Think for yourself and don't listen to somebody just because they hurt your feelings. > To pick a topical example: Is TDD hard in Rails apps because TDD is dead or because Rails makes TDD hard? This is a misrepresentation of what DHH has said 1, which is that strict adherence to TDD can make your designs worse: > Over the years, the test-first rhetoric got louder and angrier, though. More mean-spirited. And at times I got sucked into that fundamentalist vortex, feeling bad about not following the true gospel. Then I'd try test-first for a few weeks, only to drop it again when it st…

ailideexon Hacker News • Mentions

On “Ask HN: What prominent and high profile companies use TDD?”

I'm not sure I buy this. Quote from Martin Fowler: link to this video > I share with with David and Kent, there are problems where TDD doesn't work terribly well, and sadly most of the programming I do these days is not conducive to TDD and I miss it because actually I really like the TDD flow that really works for me just as it works the Kent.

dhzhzjsbevson Hacker News • Mentions

On “Unit Testing is Overrated (2020)”

Hot take. Unit testing is not overrated, if you feel this way you likely just suck at optimising your suite for high RoI tests or chase some stupid metric like code coverage getting mad when you find out you wasted a bunch of time writing worthless tests. link to this video

MarquesMaon Hacker News • Mentions

On “Ask HN: In these uncertain times, how do you handle anxiousness”

…more time, I book another time block for the next day - as simple as that. Now write that "unit test", forget it, and sleep well at night. If you really need to worry about them, you should have a "quarterly/monthly worrying day" to reflect about your life, your career, strategies and all that. Outside that day, you just live your happy life. 0 link to this video…

u/sam-the-unsinkablein r/dotnet • Mentions

On “With Dependency Injection, does every single class in use need to be injected? How do we combine this with the Clean Code principle of many small classes?”

I agree and I prefer tests with fewer mocks because it reduces coupling of the test code to the actual implementation, specially if the interface you're mocking is not very stable and I've been increasingly finding more and more literature of developers supporting this practice too, for example Kent Beck himself said that he doesn't use a lot of mocking on his tests and the new unit testing book by Vladmir Khorikov also gives arguments favoring this view. I think a lot people learn to test using the londonist approach and then start treating it as gospel. For me the main reason I introduce tests in the first place is because I'll need to make changes to the code in the future and if the t…
2View on Reddit

u/sliderhouserules42in r/dotnet • Mentions

On “Is Automapper the most hated library?”

I think I've watched that one, but I need to watch it again if I have, because I don't remember it well. (EDIT: Just watched that one again... that is a video every developer should watch. Highly recommended.) This one is also really good, from the main men themselves (4 part series): [video

u/sliderhouserules42in r/dotnet • Mentions

On “Is Automapper the most hated library?”

>At some point you will always require test changes with refactors depending on your level of changes Hmm... no. The rest of your comment, maybe, but not this. Someone else posted this in here somewhere else, but I highly recommend these: [video [video

u/sam-the-unsinkablein r/dotnet • Mentions

On “Why shouldnt you use repository pattern”

I think most people here should have a look at the Vladimir Khorikov's book about software testing. Integration tests are much more valuable in a webapi context unless you have complex domain logic, but in this case you could separate the domain logic into separate classes so that you can unit test them. The obsession with mocking everything is one of the reason some people hate writing unit tests. The tests become coupled to the implementation and then become really hard to change. And I've seen tests that only assert if the mock is running and nothing else. Testing your repository logic is not about testing if EF Core is working correctly, it's about being certain that your code is inser…