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

'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.

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]

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. 'changing a user's email address' rather than 'the setEmail method of the User class'. This improves reliability and makes failures more useful/meaningful (i.e. "this feature broke" vs "this calling convention has changed"). - Mocking is a crutch: it works-around problems that can usually be avoided entirely during design; it can still be very useful when a design can't be changed (e.g. adding tests to a legacy system). - Testing a real thing is objectively better than testing a fake thing; we should only mock if testing the real thing is unacceptable. - If two components always exist together, pretending that they're independent is a waste of time and complexity. - Having some poor tests is better than having no tests. Tests can be added, removed and improved over time, just like anything e

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] on TDD

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. [this video]

IMO, a lot of sage advice about TDD, well informed by years of practice, is in two Ian Cooper NDC talks, his controversial-at-the-time "TDD, Where Did It All Go Wrong?"[1] and, seven years later, "TDD Revisited"[2]. The blurb from the latter: > In this talk we will look at the key Fallacies of Test-Driven Development, such as 'Developers write Unit Tests', or 'Test After is as effective as Test First' and explore a set of Principles that let us write good unit tests instead. Attendees should be able to take away a 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: [this video] 2: [link]

To add to all the excellent answers in this thread: unit tests are massively overrated. It is good to know that your base64 encoding function is tested for all corner cases, but integration and behaviour tests for the external interface/API are more important than exercising an internal implementation detail. What is the external interface of the kernel? What is its surface area? A kernel is so central and massive the only way to test its complete contract with the user (space) is... just to run stuff and see if it breaks. TDD has some good ideas but for a while it had turned in a religion. While tests are great to have, a good and underrated integration testing system is just for someone to run your software. If no one complains, either no one is using it, or the software is doing its work. Do you really need tests for the read(2) syscall when Linux is running on a billion devices, and that syscall is called some 10^12 times per second globally? [this video]