My 25 Laws of Test Driven Development - Dennis Doomen - NDC Porto 2023

This talk was recorded at NDC Porto in Porto, Portugal. #ndcporto #ndcconferences #tdd #developer #softwaredeveloper
Attend the next NDC conference near you:
ndcconferences.com
ndcporto.com/
Subscribe to our CZcams channel and learn every day:
/‪@NDC‬
Follow our Social Media!
/ ndcconferences
/ ndc_conferences
/ ndc_conferences
About 15 years ago, I got inspired by the practice of Test Driven Development. Now, with many years of great and not-so-great experiences practicing Test Driven Development, I thought it is the time to capture my own “laws”. The term "law" is obviously an exaggeration and "principles or heuristics" cover my intend much better. Either way, I want to talk about the scope of testing, using the observable behavior, naming conventions, state-based vs interaction-based testing, the impact of DRY, patterns to build useful test objects and some of the libraries and tools I use. In short, everything I try to follow every day I write, review or maintain code.

[@Tango-tt6dx]

Based on my current knowledge and believes about enterprise application development, this talk reflects 100 percent how I practically develop software. Its a very pragmatic view on software developing and simultaneously does not contradict any of the concepts and principles of "traditionally taught" software development.

[@paulciorogar]

"if you test bigger you don't need mocks" this guy writes shells around a database with just a few data parameters. He never had to write 1.5k + lines of code just for the setup of a test. Then you wish you could split stuff and do mocks. Because hundreds of lines like new Point(x, y, z) is really fun to change when new requirements come.

[@Tango-tt6dx]

I got a diffrent take from the talk. Don't test too small only for the sake of having small units. Choice your test scope for reasons of requirements and value. And hopefully your project design facilates this kind of scoping.

[@Timelog88]

" He never had to write 1.5k + lines of code just for the setup of a test."
I also never had to do that 🤔Are you sure you're doing it right? When you are not mocking it really just means you write the fakes yourself, for example by making a configurable shell or wrapper around the dependency. Doing that should NEVER lead to having to write 1.5k lines of code for a setup.

[@paulciorogar]

@@Timelog88 In this particular case there is no dependency is just data, a lot of data, that represents a 2D face, or a piece of the face, of a 3D real object. The code was old not covered by tests and not modular. I could not test parts of it using mocks so I had to create fake data that represents a miniature model to test specific algos. In some cases it would be easy to mock parts that extract specific data out of this model and work with smaller data sets. Or mock checks of real dimensions and the list goes on. Testing algorithms with mocks and fake data at a smaller granularity is easier than creating real size fake data. Not to mention the amount of fakes you have to create if you are trying to test at a too high level. So a unit to test can be described as testing only one functionality but I would add that it is also about the amount of data that you need to fake in order to test it. If the amount of data is a lot you are not at the right level and need to break it intro smaller units with less data constrains for testing. I want to test that a banana is yellow but I can't make just a fake banana I need to create a fake gorilla holding the banana and a fake jungle.

[@vrjb100]

A software architect with 20 years of experience , has 0 years of recent programming experience with the latest version of the language. They are totally useless.

[@gJonii]

You wouldn't hire an architect to write production code, so knowing the latest version of language seems mostly irrelevant to the task of planning the broad strokes structure on what to build.