This video should have more views and likes than it does. The presenter makes very important and logical points which can be applied to a wide variety of systems under development.
@manish look for the talk of sandro mancuso he mentioned and also "full hour with Uncle Bob", (and follow also youtube suggested videos) I hope it helps you :)))
This guy first has been using approaches he presented for quite some time. So this is the knowledge based on practice, and he's pretty smart, then conclusions are worth to look at.
Great presentation chock-full of good advice and good examples! The only thing I wasn't impressed by was his dismissal for the need of contract tests when he answered an audience members question around the 53min mark.
This talk doesn't seem very relevant to TDD™, but it does raise some interesting unit and integration testing techniques. Stay for the questions; the speakers clarifications on IO testing misunderstandings are valuable.
TDD was inspired by Kent Beck in his book "Test driven development". Anything different than that is just misquotation and should be reffered to by a different name.
Sadly, like all other TDD presentations, it starts from the unproven premise that developer-tests are a better, more effective, method to testing compared to the other approaches that often get more coverage, and provide more confidence before deployment. Hardly anyone writing software that cannot fail without huge costs is saying "developer's mocked unit tests passed, deploy it". Just once I would like to see some sources that show the WHY of TDD cost-benefit-wise, not the HOW. For the HOW, these videos are great.
If you have multiple test types, coverage should not be cummulative. That is a naive way of seeing coverage. Developers might not write all the acceptance or e2e tests, but they should be involved in everything that is done using automation. You can have SDETs doing exploratory, showcasing, some UAT, or demos manually.
A shitload of code just because of many test cases? Ruins his credibility as how has he not been exposed to modern test frameworks that have setup and teardown methods that can be used by multiple tests.
You shouldn't use setup & teardown methods, because then you're losing context. You cannot read test from top to bottom, because there are special functions like setup and teardown - for each test case you'd have to remember about them, what they are doing. These functions are considered as anti-pattern.
@@marcinwolak241 "You shouldn't use setup & teardown methods, because then you're losing context" - debatable. I would say that those who advocate such do not have a strong basis. Test code is code and should be mantained like any other piece of your codebase. One important aspect of maintenance is reducing duplication, while keeping the code easy to navigate. If the setup and teardown are complicated when doing anything less complex than an acceptance test, this should be a red flag that your design should be reviewed and improved.
Man this guy is misleading, if you dont write test first , you dont doing TDD. Sure its hard when you need to write tests after the code has be written and this is not TDD again. So what you do ? Right, you start writing failing test and pass them one by another and in parallel you improve the codebase and refactor it , if business say dont do TDD you ask them politely : do you want that i create mess? if they say yes, you update your resume and apply at another company, because your company would not live long. Another problem is dependency on Spring framework , for me its a smell of bad design, so dont integrate your business rules into the framework and make sure that you do them via open close principle, open for extension, but close for modification or even use proxy pattern. Why dont depend on framework? Well frameworks go and get out and at some point it can get you into difficult situations and if you get in such case , well blame on yourself you get it handed to you.
one of the videos that sounds great even at 1x speed. great presentation.
This video should have more views and likes than it does. The presenter makes very important and logical points which can be applied to a wide variety of systems under development.
Even I think so, but I do not understand those dislikes, they confuse me ?
@Ivana Jetter Cool, your girlfriends insta has nasty pictures. I've never thought ..
@@Manishsharma-tj4nn They did not test.
"Business is not trained in logical thinking"
It's one of the best TDD video I've been watching last years.
Described problems are real and Jakub explains great solutions.
Great talk, I'll surely repeat it a couple of times to understand it better and start improving my TDD skills!
Please share link or topic of other related videos to learn more
@manish look for the talk of sandro mancuso he mentioned and also "full hour with Uncle Bob", (and follow also youtube suggested videos) I hope it helps you :)))
@@Manishsharma-tj4nn there's a cool presentation by Ian Cooper (TDD, Where Did It All Go Wrong).
This guy first has been using approaches he presented for quite some time. So this is the knowledge based on practice, and he's pretty smart, then conclusions are worth to look at.
Brilliant talk.
Great talk
This surprised me with how much I didn’t know about unit testing. Dude is super handsome too.
Great presentation chock-full of good advice and good examples! The only thing I wasn't impressed by was his dismissal for the need of contract tests when he answered an audience members question around the 53min mark.
Awesome video on TDD. Can someone please share the GIT link as well ?
This talk doesn't seem very relevant to TDD™, but it does raise some interesting unit and integration testing techniques. Stay for the questions; the speakers clarifications on IO testing misunderstandings are valuable.
Great talk - just makes you realise how much better Golang is for coding!
It's a real buzz when I watch talks and realise I have worked with some of the developers cited.
What language are the BDD tests written in? Groovy?
yes, Spock + Groovy
have been watching a few talks on TDD and it seems there is just as manny opposing views on the topic as if it was politics
TDD was inspired by Kent Beck in his book "Test driven development". Anything different than that is just misquotation and should be reffered to by a different name.
Not sure what he's talking about but it's certainly not TDD.
Single level of abstraction principle
Why do you mention the name of the principle? Do you think that the code and approach shown uses it?
Changing method signator breaking existing code? NO WAY, I have to re-inspect my way of coding.
Interesting. But I don't buy the idea of building up a "small DSL".
Sadly, like all other TDD presentations, it starts from the unproven premise that developer-tests are a better, more effective, method to testing compared to the other approaches that often get more coverage, and provide more confidence before deployment. Hardly anyone writing software that cannot fail without huge costs is saying "developer's mocked unit tests passed, deploy it". Just once I would like to see some sources that show the WHY of TDD cost-benefit-wise, not the HOW. For the HOW, these videos are great.
If you have multiple test types, coverage should not be cummulative. That is a naive way of seeing coverage. Developers might not write all the acceptance or e2e tests, but they should be involved in everything that is done using automation. You can have SDETs doing exploratory, showcasing, some UAT, or demos manually.
A shitload of code just because of many test cases? Ruins his credibility as how has he not been exposed to modern test frameworks that have setup and teardown methods that can be used by multiple tests.
You shouldn't use setup & teardown methods, because then you're losing context. You cannot read test from top to bottom, because there are special functions like setup and teardown - for each test case you'd have to remember about them, what they are doing. These functions are considered as anti-pattern.
@@marcinwolak241 "You shouldn't use setup & teardown methods, because then you're losing context" - debatable. I would say that those who advocate such do not have a strong basis. Test code is code and should be mantained like any other piece of your codebase. One important aspect of maintenance is reducing duplication, while keeping the code easy to navigate. If the setup and teardown are complicated when doing anything less complex than an acceptance test, this should be a red flag that your design should be reviewed and improved.
Man this guy is misleading, if you dont write test first , you dont doing TDD. Sure its hard when you need to write tests after the code has be written and this is not TDD again. So what you do ? Right, you start writing failing test and pass them one by another and in parallel you improve the codebase and refactor it , if business say dont do TDD you ask them politely : do you want that i create mess? if they say yes, you update your resume and apply at another company, because your company would not live long. Another problem is dependency on Spring framework , for me its a smell of bad design, so dont integrate your business rules into the framework and make sure that you do them via open close principle, open for extension, but close for modification or even use proxy pattern. Why dont depend on framework? Well frameworks go and get out and at some point it can get you into difficult situations and if you get in such case , well blame on yourself you get it handed to you.
@@todayisagoodday5027 Ian Cooper videos on TH-cam. Robert Martin Clean Code videos.