DevTernity Conference
11 HN recommenders · recommended in 15 months, 2018–2024
1:03:55 · 619K views · Dec 20, 2017
Ian Cooper's DevTernity talk revisits Kent Beck's original TDD ideas and shows where misunderstandings crept in. It argues tests should target behaviors through public interfaces rather than implementation details, so suites support refactoring instead of resisting it.
HN repeatedly calls it the best talk on testing, and many say it changed how they approach tests, mocks and the meaning of a unit.
20 comments from Hacker News
The best talk on this topic, IMO is Ian Cooper: "TDD, Where did it all go wrong?" 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 unit, because most classes are only consumed within a single unit. - Behavior driven testing makes most sense to decide what needs tests. If it's required behavior to the people across the boundary, it needs a test. Otherwise, tests may be extraneous or even harmful. - As such, a good trigger rule is "one test per desired external behavior of the unit, plus one test per bug fixed". The test for each bugfix comes from experience -- they delineate tricky parts of your unit and enforce workign code around them.
> Firstly if the dependency isn't doing any io, you can test your code as a whole along with its dependency. No need to mock. This the thing. People have a tendency to overuse mocks. The point of automated testing (whether it's unit tests or something else), is to enable refactoring. That's really the only reason. Code that you don't touch doesn't suddenly change its behaviour one day. In a previous jobs the developers started to go crazy with mocking and it reached a kind of singularity where essentially if 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! this video
'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" this video Also, I thought continuous testing was having your test pack run all the time while coding, but hey ho.
This the best talk I've ever seen about testing (Ian Cooper): 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.
Ian Cooper talked about this (and more) 5 years ago: this video Well worth listening to this talk. It completely changed the way I did testing.