Great talk. First time that I heard from someone make the connection between hexagonal architecture and TDD. It was a "WoW" moment for me. I'll keep pulling on that thread.Thanks!
Unit tests are the ones you write because you are afraid you will screw things up. Integration tests are the ones you write because you are afraid of other developers and systems. End to end tests are the ones you write because you are afraid of the user.
@@Rick104547 integration tests and unit tests serve different purposes. To say integration tests work just as well as unit tests misses the point. Yes, integration tests work well for testing integration, but they are wholey ineffective for testing a unit. As you tie components together the volume of variables and dependencies required to construct any given test will become unwieldy. The point of a unit test is to interate rapidly on the smallest possible unit of work. This is possible because there are no external dependencies and the variables required to construct a test are minimized.
@@7th_CAV_Trooper I disagree, depending on what you are writing integration tests can be a better tool to iterate on than unit tests. Context is really the keyword here. Test behaviors and not implementation, maybe that means you need integration tests instead of unit tests. They can be really fast as well. Mine usually run in 100ms and run parallel so even having hundreds is not a problem at all.
Probably I am just the slow one because I live and die in a debugger, could not develop a system without one. It gives me insight how my logic match-up with the requirement because most of the time I am wrong. Most of my code were compartmentalized so unless I change something somewhere I just need to debug that portion again. Yes it is expensive but for me manual testing, with debugging, is the best way to learn about my code and design with the side effect of minimizing bugs. Manual testing forces you to think within the context of the whole system (zero mocks). I observe that most developers now could not or do not know how to QA their own work. Partly because they don't truly know what the whole system does, they only know portions of it. Like the famous quote of Jim Coplien - "today's motto in software shops is we don't need to know it, we just need to improve it".
Thank you, Gui. The flywheel analogy resonates with me. I remember working hard to turn Kent Beck's ideas into habits, but now I can't imagine developing any other way. Amazing that people still resist TDD in 2024.
The people that resist it just havent read enough on testing and havent practiced it enough. After some time it is more comfortable writing tests than running your code manually.
@@lerinarazafy7826 The usual saying that to do X thing correctly you gotta do more X is a mistake said by a lot of people promoting TDD, i think what is missing is how to get familiar with it and show actual examples and not how to TDD addition.
Great talk. First time that I heard from someone make the connection between hexagonal architecture and TDD. It was a "WoW" moment for me. I'll keep pulling on that thread.Thanks!
Unit tests are the ones you write because you are afraid you will screw things up.
Integration tests are the ones you write because you are afraid of other developers and systems.
End to end tests are the ones you write because you are afraid of the user.
Amazing
Unit tests are the ones you write to explore and iterate over the domain context.
Tbh integration tests work just as well with TDD. Just have to know how to write them (tip testcontainers are your friend).
@@Rick104547 integration tests and unit tests serve different purposes. To say integration tests work just as well as unit tests misses the point. Yes, integration tests work well for testing integration, but they are wholey ineffective for testing a unit. As you tie components together the volume of variables and dependencies required to construct any given test will become unwieldy. The point of a unit test is to interate rapidly on the smallest possible unit of work. This is possible because there are no external dependencies and the variables required to construct a test are minimized.
@@7th_CAV_Trooper I disagree, depending on what you are writing integration tests can be a better tool to iterate on than unit tests. Context is really the keyword here. Test behaviors and not implementation, maybe that means you need integration tests instead of unit tests.
They can be really fast as well. Mine usually run in 100ms and run parallel so even having hundreds is not a problem at all.
Great talk, although parts of it seem to mirror Ian Cooper’s famous TDD talk. The flywheel analogy was great!
Probably I am just the slow one because I live and die in a debugger, could not develop a system without one. It gives me insight how my logic match-up with the requirement because most of the time I am wrong. Most of my code were compartmentalized so unless I change something somewhere I just need to debug that portion again. Yes it is expensive but for me manual testing, with debugging, is the best way to learn about my code and design with the side effect of minimizing bugs. Manual testing forces you to think within the context of the whole system (zero mocks). I observe that most developers now could not or do not know how to QA their own work. Partly because they don't truly know what the whole system does, they only know portions of it. Like the famous quote of Jim Coplien - "today's motto in software shops is we don't need to know it, we just need to improve it".
Thank you, Gui. The flywheel analogy resonates with me. I remember working hard to turn Kent Beck's ideas into habits, but now I can't imagine developing any other way. Amazing that people still resist TDD in 2024.
The people that resist it just havent read enough on testing and havent practiced it enough. After some time it is more comfortable writing tests than running your code manually.
@@giorgos-4515 yes, with well organized tests I can iterate much faster than I did in the old days.
Its the "multi-level marketing" like ecosystem that grew around TDD that people really resist.
@@lerinarazafy7826 The usual saying that to do X thing correctly you gotta do more X is a mistake said by a lot of people promoting TDD, i think what is missing is how to get familiar with it and show actual examples and not how to TDD addition.
@@giorgos-4515 or maybe people are just too lazy to read books and try it for themselves?
I enjoy writing unit tests, but every pro-TDD video on TH-cam is about how great unit testing is, rather than how TDD itself is actually useful.
Love -> Marriage -> when is the great divorce scheduled?
*again and again and again...
tdd is beauty, tdd is my soul,
tdd is the way of life, more than just a tool...
I need to watch the video until 1:25 to find out what TDD in this video means. Test Driven Design ot Type Driven Design. I know both topics
Video Summary: Try TDD. How do you do it correctly? Buy his course to find out....
Dude he said im not here to teach you TDD
Not even close to a useful summary, old dude.
Old dude you have to watch more than the first four minutes.
Nope. You didn't watch the conference. In one hour you have general tips and advices. It's impossible to understand TDD in one hour.
Blah blah blah🤦♂️