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

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

in “Horrible Code, Clean Performance” · View on HN

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): ▶ this video

in “Testing Without Mocks: A Pattern Language” · View on HN

That's the right way to do TDD, see this talk: ▶ 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"

in “I have complicated feelings about TDD” · View on HN

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]

in “I have complicated feelings about TDD” · View on HN

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

in “CUPID – the back story” · View on HN

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: ▶ this video

in “My Python testing style guide (2017)” · View on HN

Mandatory 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)

in “Best Practices for Testing in Java (2019)” · View on HN

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

in “Ask HN: What overlooked class of tools should a self-taught programmer look into” · View on HN

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

in “Is High Quality Software Worth the Cost?” · View on HN

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 :)

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

It is quite unlikely that a regulator will ask you for proof you have a unit test for anything (also, that's not what a unit test is - see [1] for a good summary of why). It _is_ likely a regulator will ask you to prove that you are developing within the quality assurance framework you have claimed you are, though. Finally though, logs are not an audit trail, and almost no-one can prove their logs are correct with respect to the state of the system at any given time. [1]: ▶ this video

in “Binance built a 100PB log service with Quickwit” · View on HN

The problem with tests is the TDD dogma, which wastes time and makes code harder to change (because even reasonable changes break a bunch of tests). There's a good rule of testing top level behaviors described in this talk [1] For code reviews, it's about knowledge handoff. No one disputes you can write great code alone. The problem is that singular geniuses writing functional but unmaintainable code only they understand and then getting hit by a bus or changing jobs is a real issue. 1. ▶ this video

in “SumatraPDF Reader” · View on HN

If AI can write your tests, you're testing likely implementation details. This has "negative value"! ▶ this video But an AI can't write higher level tests as it would need to understand large chunks of code (sometimes whole systems), which it can't.

in “Lessons from Creating a VSCode Extension with GPT-4” · View on HN

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

in “Ask HN: Why the Linux Kernel doesn't have unit tests?” · View on HN