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

What Hacker News said

Strong rec macca321 · 2018-11 · 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" [this video] Also, I thought continuous testing was having your test pack run all the time while coding, but hey ho.

Strong rec VHRanger · 2020-08 · on “Is TDD Dead? (2014)”

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

Strong rec globular-toast · 2021-03 · on “CUPID – the back story”

> 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 poi

Strong rec globular-toast · 2022-01 · on “Favor real dependencies for unit testing”

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.

Strong rec globular-toast · 2024-04 · on “Unit Tests Considered Harmful”

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.

Recommends macca321 · 2018-11 · 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 [this video] I post this all the time, it's like free upvotes :)

Recommends chriswarbo · 2019-05 · on “Ask HN: What overlooked class of tools should a self-taught programmer look into”

I find [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

Recommends benjiweber · 2019-05 · on “Is High Quality Software Worth the Cost?”

I see this opinion a lot from people who haven't seen tests and code written by people experienced with TDD. The tests should not end up that coupled to the code. The implementation structure and the test structure end up somewhat different when refactoring every time the tests are green. When listening to the feedback from the tests & 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 [this video] and [LINK