TDD Revisited - Ian Cooper - NDC Porto 2023

This talk was recorded at NDC Porto in Porto, Portugal. #ndcporto #ndcconferences #testing #tdd #softwaredeveloper
Attend the next NDC conference near you:
ndcconferences.com
ndcporto.com/
Subscribe to our KZbin channel and learn every day:
/@NDC
Follow us on our Social Media:
/ ndcconferences
/ ndc_conferences
/ ndc_conferences
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"

[@IAMAliJan]

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

[@abdullahkarolia3418]

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

[@samba2133]

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.

[@JohnFarrellDev]

full end to end and integration testing

[@ForgottenKnight1]

Use DI when needed (like strategy pattern or other patterns where you don't know the concrete dependency before runtime or there can be different dependencies based on conditions in layers above). And stop writing unit tests for internal or private classes. Test public classes, more specifically public methods in those public classes. Mocking couples implementation details to the test, which will make the test fail if you change the implementation, even if the behavior remains the same.

[@BryonLape]

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.

[@xuscrus]

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

[@ForgottenKnight1]

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.

[@KyleSmithNH]

Wait do europeans still drive stick?

[@pepijnkrijnsen4]

Sure do! We had a continent wide vote on it a while ago and stick won out.

[@gruttewibe76]

Electric and hybrid cars are often automatic only, I think, so manual gearbox is probably going away slowly.

[@nazarshvets7501]

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

[@zhenyuzhang761]

It make sense to me. Here is why. Prerequisite about who I am. - I don't follow anything, I make tradeoff. - I don't care about detail, those IO, UI stuff. I only care about doamin logic. For your second point, I don't force 100% on everything, I force 100% on the doamin logic that I care. For your first point, I have a clearly defined inside layer which is my domain in my codebase. Inside doamin there are properly divided modules, I treat each module as a black-box and test their public methods that will be called by other modules. About this you may need to learn about DDD and component/module. Hope my experience could help.

[@ForgottenKnight1]

Go read Test Driven Development by Kent Beck. It contains some clarifications to your questions...