Skip to content
0:00 / 0:00

#tdd#unittesting#mocking

🚀 TDD, Where Did It All Go Wrong (Ian Cooper)

DevTernity Conference

12K subscribers • 2 videos on Hallway

YouTube
  • Recommended by 12 people: 11 on Hacker News and 1 curated list.
  • A classic. People kept recommending it from 2018 to 2024.
  • Presented by Ian Cooper
  • An opinion. It argues one side of a question engineers disagree on.

Intermediate. Assumes working knowledge.

619K views8 years ago12 recommendations

Tools and practiceSoftware designTestingRefactoring and legacy codeDesign patterns

Ian Cooper revisits Kent Beck's original ideas on TDD, explaining how common misunderstandings about unit tests and mocking make test suites brittle.

🗓️ Upcoming developer events: dev.events Since Kent Beck wrote the book on TDD in 2002 a lot of words have been dedicated to the subject. But many of them propagated misunderstandings of Kent's original rules so that TDD practice bears little resemblance to Kent's original ideas. Key misunderstandings around what do I test, what is a unit test, and what is the 'public interface' have led to test suites that are brittle, hard to read, and do not support easy refactoring. In this talk, we re-discover Kent's original proposition, discover where key misunderstandings occurred and look at a better approach to TDD that supports software development instead of impeding it. Be prepared from some sacred cows to be slaughtered and fewer but better tests to be written.

Why it's here

12 people recommend this

What people say. Highly recommended as a paradigm-shifting talk that changes how developers approach unit testing and refactoring.

Moments people linked to

macca321on Hacker News • Recommends

On “Signs you are doing continuous testing wrong”

'Test Pyramid' considered harmful IMO. It discourages people from writing tests against the public interface of their system , and instead encourages testing against internals. This leads to a test pack that prevents refactoring, and can't be trusted to catch regression errors. This is partly down to the widely confused definition of a 'unit test' (which a lot of people interpret as 'one test per class'). If you haven't seen it, please watch Ian Cooper's "TDD, Where Did It All Go Wrong" link to this video Also, I thought continuous testing was having your test pack run all the time while coding, but hey ho.

VHRangeron Hacker News • Recommends

On “Is TDD Dead? (2014)”

The best talk on this topic, IMO is Ian Cooper: "TDD, Where did it all go wrong?" link to this video Couple of notes: - TDD, much like scrum, got corrupted by the "Agile Consulting Industry". Sticking to the original principles as laid out by Kent Beck results in fairly sane practices. - When people talk about "unit tests", a unit doesn't refer to the common pattern of "a single class". A unit is a piece of the software with a clear boundary. It might be a whole microservice, or a chunk of a monolith that is internally consistent. - What triggers writing a test is what matters. Overzealous testers test for each new public method in a class. This leads to testing on implementation details of the actual…

globular-toaston Hacker News • Recommends

On “CUPID – the back story”

…a function called anything, that thing was mocked. It definitely tests each function in complete isolation, but what's the point? It makes refactoring impossible, which is the entire point of the tests in the first place! This excellent talk completely changed the way I approached testing. Every developer who writes tests needs to watch this now! link to this video…

globular-toaston Hacker News • Recommends

On “Favor real dependencies for unit testing”

Ian Cooper talked about this (and more) 5 years ago: link to this video Well worth listening to this talk. It completely changed the way I did testing.

globular-toaston Hacker News • Recommends

On “Unit Tests Considered Harmful”

This the best talk I've ever seen about testing (Ian Cooper): link to this video I see he's done a much more recent follow up, which I intend to watch: link Not sure if it contains new ideas. He says the unit is not "a class" but a module. It's up to you to decide what the module does (ie. what level of abstraction it's at). More importantly, he argues against mocking and essentially "unit testing" in most cases.

programming-talkscurated list on GitHubRecommends

Under “Software Development”

TDD, Where Did It All Go Wrong 01:03:53 by **Ian Cooper** (2017)

macca321on Hacker News • Recommends

On “Ask HN: What's the largest amount of bad code you have ever seen work?”

For those who want to know more about this approach: see Ian Cooper - TDD, Where Did It All Go Wrong link to this video I post this all the time, it's like free upvotes :)

chriswarboon Hacker News • Recommends

On “Ask HN: What overlooked class of tools should a self-taught programmer look into”

I find link to this video describes my own experiences with automated testing quite well. tl;dr: - Focus on "automated testing", don't get obsessed with philosophising about "the true nature of a 'unit'", or other such dogma. - Be empirical: base your rules on what works; don't base your work on "the rules". - The goal of testing is to expose problems in our program: "test failure" is a success, because we've found a problem (even if that problem is with the test!). Anything else is secondary (e.g. isolating the location of failures, documenting our API, etc.). Avoiding this goal defeats the point (e.g. choosing to ignore edge cases). - Focus on functionality rather than implementation details, e.g. 'c…

benjiweberon Hacker News • Recommends

On “Is High Quality Software Worth the Cost?”

…ts & code. With the skills to spot the refactoring opportunities. Oftentimes people seem to equate unit testing with a 1:1 correspondence of test and implementation with high coupling between the two. These sort of tests resist refactoring, rather than enabling it. With good tests you can pivot the implementation and tests independently. Recommend link to this video and link on TDD…

bederson Hacker News • Recommends

On “Best Practices for Testing in Java (2019)”

Mandatory link to link to this video It clarifies a few of the points made in the article. Personally I would add: Don't overuse mocks, only use dependency injection on the module level (Ludicrous use of singleton DI will hinder your design, not help it)

snidaneon Hacker News • Recommends

On “CUPID – the back story”

You are doing interface/function level testing and calling it unit testing. That's what industry converged on, that a function/method = a unit, but it apparently used to be that a module meant to be a unit. It can be that both interfaces and modules can be considered a "bag of functions". Seems like a lot of confusion about unit testing, mocking and DI stems from this historical shift. I believe that interface/method level testing is too granular and mostly results in overfitted tests. Testing implementation, not behaviour. Which can be useful for some algorithm package for example, but probably not so much applicable to typical business logic code. TDD: where did it all go wrong. link to this video

globular-toaston Hacker News • Recommends

On “My Python testing style guide (2017)”

Just don't use them unless you have to. The two main reasons to mock are for network requests and because something is too slow. Other than that, test things for real. Do not isolate parts of your code from other parts of your code by using mocks. If your code does side effects on your own machine, like writes to the file system, let it write to a temporary directory. I linked this excellent talk in another thread recently. I'll put it here again: link to this video

imran-iqon Hacker News • Recommends

On “I have complicated feelings about TDD”

That's the right way to do TDD, see this talk: link to this video One of the above comments mentions BDD as a close cousin to TDD, but that is wrong as TDD is actually BDD as you should only be testing behaviours, which allow you to "fearlessly refactor"

ttctciyfon Hacker News • Recommends

On “I have complicated feelings about TDD”

…clear set of guidelines as to how they should be approaching TDD to be successful. The session is intended to be pragmatic advice on how to follow the ideas outlined in my 2013 talk "TDD Where Did it All Go Wrong" The talks focus on reasons to avoid slavish TDD and advocate for the benefits of judiciously applying TDD's originating principles. 1: link to this video 2: link…

elboruon Hacker News • Recommends

On “Testing Without Mocks: A Pattern Language”

There's a middle tier, broad tests in the sense of not mocking local dependencies but only external (slow) ones. Many developers mock every dependency in a SUT, even if they own the dependency. I like the idea of broad tests that run-in memory (no I/O interaction). I think Ian Cooper does a great work explaining it in this talk (he talks about TDD, but I think the main idea applies even if you write tests after code): link to this video

imran-iqon Hacker News • Recommends

On “Horrible Code, Clean Performance”

That's why TDD is about testing requirements and not implementations. The problem is most people dont know what TDD is: link to this video