TDD Revisited - Ian Cooper - NDC Porto 2023

This video should be shared more. Everyone needs to go back to basics

This finally made testing as a whole concept make sense...

Thanks to be reminded on the focus on behavior. Dealing with a modern dotnet code base, we do DI all over the place and mostly fall back on mocks. I'd love to understand the alternatives better.

There is a built-in Audacity plugin that can remove the background hum by giving it a sample of it from where there are no other sounds in the source.

I tend to mock, fake, or stub on the edges for tests that last. May use it when I'm discovering internal implementation and just need something to pretend to work. These tests tend to get removed over time.

I Love the "using the word micro in micro services" 👏👏👏

I'm confused about "only test the public interface that other people depend upon" at 28:04. The implication of that seems to be that if the entire system is developed by one team with full collective code ownership, then you should only test at the user or other external interface of the application. But that can't be right, since testing at the user interface level is generally hard work and fragile. So maybe it means have the app split into modules and test at the module boundary level. But then the problem of what to test isn't really answered, it's just replaced with the problem of how to decompose the app into modules, and if you change that arrangement of modules you'll still need to change the tests. And not all languages have a native module system where a module is distinct from a class or a function. And writing a test for a module may be a lot more complicated and require a lot of irrelevant details that gets in the way. E.g. in the example of calculateFoo, if Foo is something that the customer understands (e.g. foo is the postageAndPackagingCostEstimate for display on a shopping cart) then having a focused test that calls that function or something close to it seems a lot simpler than a test on a bigger scale where more setup is required so we can call a bigger function that e.g. also has to calculate the taxes.

Merging development and QA was a very bad decision that corporations made. Now, their agenda is obvious, more profit, but the outcome is software of lower quality. QA is a different mindset than development itself, and having the developer only testing his code is just asking for trouble because of all sorts of biases.

Wait do europeans still drive stick?

Didn't make sense to me. - Testing behaviour as black box is basicly E2E tests. It is known fact that there are expensive, so you don't want to make 100% coverage by them, only happy paths. The rest should be covered by other kind of tests: units, integration etc - How its expected to get 100% coverage "out of the box" if you are not supposed to TDD whole codebase. Сausal relationship is self referential here, therefore is invalid. - What exactly you testing by TTD, if its not: IO, Http, Database, UI, Defined Spec. If its not units, not integration, then its E2E? (see point 1) Are u building features without specification? How is that supposed to even work? What are u discovering there? Funny tho, TTD guys usually say that its a skill, but if you discovering implementation by TTD, it is looks like a skill issue. I think there is lack of practical examples