Thank you, Dan, for this great content. I am looking forward to the next part, where you show us how the interplay between integration test and test container can be used. I love this channel. Thanks again.
Oh Yee, that is great.Although this is the right way First write a test then the code, but I don't do it. Either knowledge deficiencies or I am not so sure to do it. Thank you so much. I have learned a new technique today and you helped me a lot with this TDD. Thank you God bless you🙏
Thank you, I am learning a lot. I see some gaps in your round TDD, like the list of (improvements, issues, and smell code) that list is part of the concept of driving code to the next level. Another gap is the refactore in bove production code and test code because that can be aply when you repeat some parts of the test code, or for example, the moment you see the difficulty of isolating the test from de repository layer, when this issue pops up is a good time to try to refactor the code.
what I like about hexagonal architecture is the ability to isolate your business logic and test it independently from the framework / DB. it can be pure java without any dependencies, so we can test the most important part of the app quickly and iterate faster!
In order to have maintainable tests, you should add additional layer which hides communication details of the REST client. Just introduce records to wrap the request and response and express the test semantics as plain as possible. Of course it adds time and complexity, but at the end it will help the team not to either create a mess in the tests or just abandon writing them. Also never use the objects (entity, dto) from the main code in your test, because if you change the JSON key name, effectively breaking the clients, tests will not catch that, because refactoring will rename everywhere.
Actually @Dan Vega, AutoConfigureMockMvc annotation is not necessary in order to use MockMvc. It's only when you want to do fine-grained configuration you'd need this.
Haven't used java for some years (kotlin). Does anyone know why mockMvc and posts in PostControllerTest (at 18:23) are not private like they used to be? Allowing access outside the test class seems wrong.
The title is misleading: Dan shows some of the test-related features of Spring but that has nothing to do with actual TDD, is applies to just any automated test method. Dan mostly uses instead the "test last" method.
Hi Dan! Wonderful tutorial. However I have to point out few things you did wrong. It has to do mostly with using Post record with POST & PUT. You should have used DTO instead, because you should not pass the ID of the Post in the request body, when you create or update. And since you are validating the records, it would fail if you tried to exclude them. Or at least it should fail - they should be mandatory :) Also you arbitrarily decided which attributes can be updated, which is not correct - in case of PUT, you update everything with the exception of an ID. If you do not provide new value, it is empty by default. Other than that - I have no objections - nicely done and I can not wait to see your next tutorial on integration / unit tests. P.S.: Just an idea - it would be great, if you could do the whole series on different types of tests - so for models / records, repositories, services, controllers, etc. Thanks!
@@sergey--24You are right, @Id annotation comes from JPA and isn't related to dto validation. Validation annotations are the ones marked with @Constraint from jakarta.validation. But still the OP has a good point that id shouldn't be included in PUT nor POST requests. Dan probably knows that, but he did set a poor example by accident
@@hesik3461 As far as I got it - Dan just wanted to avoid using the classic approach (DTO + Entity). He used just one data carrier - Post record, to show the new possibilities of using records in Spring Data JPA. Anyway, for PUT method id is required as path variable. And as we've already figured out - @Id fields aren't validated by applying @Valid annotation. So he could’ve left id field empty and put responsibility of identity generation on DB.
I liked the theme, what is it? You could leave your setup settings fixed, it's irrelevant, but people like me like that. And congratulations on this beautiful video.
Hi Dan, I'm just wondering how Java and Spring are used in VMware. I always believed they use something low-level to achieve the best performance with virtual machines. Where does Java fit into all of this? :)
The comment about the epics, stories and features at ruclips.net/video/-H5sud1-K5A/видео.html is vital. Initially, I thought TDD was just about writing the test for your REST Controller methods, i.e, you are focused on writing tests for your methods first. But the idea of TDD is not testing a method but testing your system's behaviour/requirement/use cases.
I like your videos and I have been following you since 2018. Your content quality has been going up a lot lately!! Regarding the topic, This is nice an all, but how do you approach TDD when you have a massive legacy app without tests and complex object(json) structures composed of quite a few objects, with a lot of db interactions (while many times you don’t have control over the db)..this is the truth most of the times in the java world. Don’t get me wrong, I love the video and thank you for the effort. I would like to see a more “realistic” approach, that’s all.cheers
Omg Dan... When I see you writing code... It's a beautiful experience, you do it with a lot of quality and wisdom. excellent video about TDD!
Bro👀
Thank you, Dan, for this great content. I am looking forward to the next part, where you show us how the interplay between integration test and test container can be used. I love this channel. Thanks again.
Coming soon!
Beatiful way to explain TDD, write the application using it. Thank you very much Dan.
Terrific Development with Dan, indeed
Oh Yee, that is great.Although this is the right way First write a test then the code, but I don't do it. Either knowledge deficiencies or I am not so sure to do it.
Thank you so much. I have learned a new technique today and you helped me a lot with this TDD. Thank you God bless you🙏
Thank you, I am learning a lot.
I see some gaps in your round TDD, like the list of (improvements, issues, and smell code) that list is part of the concept of driving code to the next level.
Another gap is the refactore in bove production code and test code because that can be aply when you repeat some parts of the test code, or for example, the moment you see the difficulty of isolating the test from de repository layer, when this issue pops up is a good time to try to refactor the code.
This is a truly amazing video. Thanks Dan.
I appreciate that! Thank you 🙏
It was a great one Dan!! keep coming with it !!!!!
Thank you for TDD series
LOL your timing on this video is AWESOME
I have learned a lot with your daily videos. You make me want to quit my Javascript job and look for a Java one , idk why.
funny how we Java developers think the opposite, grass is always greener huh
@@kagenashi2286do we?😅
Javascript is a pain in the ass dude!
@@kagenashi2286talk for yourself, I worked with both and will always prefer Java instead of the hell of JavaScript haha
Actually I am a full stack dev. When am working on JavaScript/ Typescript I miss the simplicity of java and vice versa😂😂😂
Thanks for this tutorial ! awesome !
Thank you ❤
what I like about hexagonal architecture is the ability to isolate your business logic and test it independently from the framework / DB.
it can be pure java without any dependencies, so we can test the most important part of the app quickly and iterate faster!
Big thanks for this tutorial
Great explanation, thaks a lot ❤🙂🙌
Hey Dan, Amazing content. Learnt so much. Just wanted to know the IntelliJ theme u r using, it seems very soothing for eyes.
Great video, Dan.
In order to have maintainable tests, you should add additional layer which hides communication details of the REST client. Just introduce records to wrap the request and response and express the test semantics as plain as possible. Of course it adds time and complexity, but at the end it will help the team not to either create a mess in the tests or just abandon writing them. Also never use the objects (entity, dto) from the main code in your test, because if you change the JSON key name, effectively breaking the clients, tests will not catch that, because refactoring will rename everywhere.
Actually @Dan Vega, AutoConfigureMockMvc annotation is not necessary in order to use MockMvc. It's only when you want to do fine-grained configuration you'd need this.
Dude, you are awesome.
37:58 It’s necessary to mock what repository returns when request body is invalid?
Haven't used java for some years (kotlin). Does anyone know why mockMvc and posts in PostControllerTest (at 18:23) are not private like they used to be? Allowing access outside the test class seems wrong.
The default scope in Java is package / private so I'm allowing anything within the same package access to it. This isn't public.
The Ted Danson Placeholder Service
The title is misleading: Dan shows some of the test-related features of Spring but that has nothing to do with actual TDD, is applies to just any automated test method. Dan mostly uses instead the "test last" method.
Right... the test requires a 2xx status code - let's setup the database 🙂
Hi Dan! Wonderful tutorial. However I have to point out few things you did wrong. It has to do mostly with using Post record with POST & PUT. You should have used DTO instead, because you should not pass the ID of the Post in the request body, when you create or update. And since you are validating the records, it would fail if you tried to exclude them. Or at least it should fail - they should be mandatory :)
Also you arbitrarily decided which attributes can be updated, which is not correct - in case of PUT, you update everything with the exception of an ID. If you do not provide new value, it is empty by default.
Other than that - I have no objections - nicely done and I can not wait to see your next tutorial on integration / unit tests.
P.S.: Just an idea - it would be great, if you could do the whole series on different types of tests - so for models / records, repositories, services, controllers, etc. Thanks!
I guess @Id isn't supposed to be validated by @Valid - it's simply declaration that field is primary identifier.
@@sergey--24You are right, @Id annotation comes from JPA and isn't related to dto validation. Validation annotations are the ones marked with @Constraint from jakarta.validation.
But still the OP has a good point that id shouldn't be included in PUT nor POST requests. Dan probably knows that, but he did set a poor example by accident
@@hesik3461 As far as I got it - Dan just wanted to avoid using the classic approach (DTO + Entity). He used just one data carrier - Post record, to show the new possibilities of using records in Spring Data JPA.
Anyway, for PUT method id is required as path variable.
And as we've already figured out - @Id fields aren't validated by applying @Valid annotation.
So he could’ve left id field empty and put responsibility of identity generation on DB.
I liked the theme, what is it? You could leave your setup settings fixed, it's irrelevant, but people like me like that. And congratulations on this beautiful video.
Which theme do you used in the video?
Hi Dan, I'm just wondering how Java and Spring are used in VMware. I always believed they use something low-level to achieve the best performance with virtual machines. Where does Java fit into all of this? :)
Thanks alot for this. But they TDD is always seriously demanded where I currently live
Hello Dan, congrats for the contents! This is very awesome.
I'd like know what IDE is this?
Thanks!
intellij
@@shiddarthbista2248
Looks so different.
Do you know the theme?
@@kelsonmenezes5560 it's the new ui
@@kelsonmenezes5560 vc soh precisa habilitar a nova UI. Settings > Appearance & Behavior > New UI > Enable new UI
@@kelsonmenezes5560 It's the New UI that you can enable in Intellij. Don't know about the font though.
Do you know how to deploy spring boot 3 gradle project with wildfly?
The TDD mantra:
Red -> Green -> Refactor!
Coffee->Red -> Green -> Refactor!
The comment about the epics, stories and features at ruclips.net/video/-H5sud1-K5A/видео.html is vital. Initially, I thought TDD was just about writing the test for your REST Controller methods, i.e, you are focused on writing tests for your methods first. But the idea of TDD is not testing a method but testing your system's behaviour/requirement/use cases.
what is the IDE name used in the tutorial?
IntelliJ
Why Spring Data Jdbc and not Spring Data JPA?
What's your IDE theme name
I like your videos and I have been following you since 2018. Your content quality has been going up a lot lately!!
Regarding the topic, This is nice an all, but how do you approach TDD when you have a massive legacy app without tests and complex object(json) structures composed of quite a few objects, with a lot of db interactions (while many times you don’t have control over the db)..this is the truth most of the times in the java world. Don’t get me wrong, I love the video and thank you for the effort. I would like to see a more “realistic” approach, that’s all.cheers
Alphonso Branch
Walter Loaf
shame on you forced test writer :)