Improving your Test Driven Development in 45 minutes - Jakub Nabrdalik
HTML-код
- Опубликовано: 25 июн 2024
- I’ve been using TDD/BDD at work for the last 12 years, I also teach and mentor teams on this subject. I’ve found that misconceptions and errors in this field are shared, and that most of us make the same mistakes. Give me 45 minutes of your time, and I’ll try to address the most common problems, hoping to improve your TDD/BDD situation as much as possible.
I’ll try to solve:
Long running tests problem, by bringing back the correct shape of test-pyramid with power of Hexagonal Architecture (Ports & Adapters) with practical examples in Spring.
Miscommunication and lost art of requirement gathering, by focusing on readability, introducing just enough of Domain Specific Language, and sorting out what is important with the power of Spock.
Difficult test setup and environment requirements, by using command and conquer, modularity, monitoring.
Mock abuse, by showing what are the benefits of in-memory implementations.
And hopefully more.
Most teams that do not write tests first do it, because it’s hard for them. I’ll try to show you, how to make it easy. Real life examples included.
If you are not using TDD/BDD, this might also interest you - you’ll know how to start the right way. 
Кино
one of the videos that sounds great even at 1x speed. great presentation.
It's one of the best TDD video I've been watching last years.
Described problems are real and Jakub explains great solutions.
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"
Brilliant talk.
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 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).
Awesome video on TDD. Can someone please share the GIT link as well ?
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.
This surprised me with how much I didn’t know about unit testing. Dude is super handsome too.
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
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.
Great talk - just makes you realise how much better Golang is for coding!
Not sure what he's talking about but it's certainly not TDD.
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.
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.
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.
what would you recommend as a good TDD study in java for a beginner about to hit the market. I'm already in school but wanted some to the point information.
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.