Just getting into the video but am impressed with the level of explanation so far. There's a lack of quality testing videos with jest on youtube, thanks for doing this for the community! Personally I struggle so much with writing tests, especially when its for code that I didnt write that didnt follow TDD. Being able to confidently write unit tests to prove why the code needs to be refactored is a seriously good skill to have in a job. Especially when the code that needs to be refactored was written by a more senior engineer.
I definitely agree, and once you get some skill at it, it can be a difficult thing to figure out how to teach. I've been keeping my eye out for good real world examples to show but I haven't been put back in the "legacy" refactor position in a bit.
@@mondo1926 No problem, and to be clear, it's not a book about testing but the concept of having tests before refactoring is talked about a chunk in it and helped me get into the right zone of thinking when I was newer to this stuff. I've still got plenty to learn. GL to ya.
First request I've had for it. I do think it would be worthwhile, but do you have any ideas of what you'd like to see covered in it? More of a full set up from scratch type video, or just an overview of how to add certain actions/pipelines to your project? And any specific CI operations, like testing or linting, etc.
@@SwashbucklingwithCode I am getting a strange issue where it marks a template string literal such as: const MY_URL = `${BASE_URL}/foo` as "else branch not covered". Have you ever run into something like this? The BASE_URL is a const top-of-file String
@@lucasrmendonca My guess is that nothing is trying to use `MY_URL` without `BASE_URL` existing, though if it's declared in the same file outside of any function scope that does seem a bit strange to me.
@@SwashbucklingwithCode maybe this is getting transpiled by babel-jest into es5 or something so the coverage tool sees something in these lines that we don't? 🤔
Ive implemented both these checks into my ci - global and folder level. But 1 problem i face is that mine is a really large codebase - and I want to add a more granular check over coverageThreshold check - such that coverageThreshold module check will only fire - if a developer changed that file - not if doesn't include any change for that module. example: if i set coverageThreshold > "module - 1 - path" : {statements: 40}, "module - 2 - path" : {statements: 50} then if some developer changes / adds code to "module - 1 - path" - only then fire the 40% check ? is this possible ?
![ไลฟ์สุ่ม iPhone 295 บาท... โกงมั้ย?[ โกงมั้ยครับ ep.97 ] | DOM](http://i.ytimg.com/vi/gdstHEE4UUE/mqdefault.jpg)
Thank you for going into so much detail and showing how it all works with an example project!
This one hasn't gotten much attention so far, so I'm really happy to hear someone found it useful.
Really useful to me to understand how to achieve coverage step by step. Thanks a lot for making this tutorial.
I'm pleased it was helpful, thank you for letting me know.
Great tutorial I have seen on Jest test case and it's coverage report. Good going bro....
Just getting into the video but am impressed with the level of explanation so far. There's a lack of quality testing videos with jest on youtube, thanks for doing this for the community!
Personally I struggle so much with writing tests, especially when its for code that I didnt write that didnt follow TDD. Being able to confidently write unit tests to prove why the code needs to be refactored is a seriously good skill to have in a job. Especially when the code that needs to be refactored was written by a more senior engineer.
I definitely agree, and once you get some skill at it, it can be a difficult thing to figure out how to teach.
I've been keeping my eye out for good real world examples to show but I haven't been put back in the "legacy" refactor position in a bit.
If you (or anyone reading) have not read Refactoring by Martin Fowler, that is a good place to start, imo.
@@SwashbucklingwithCode Thanks for the book recommendation. It looks like a great place to start :D
@@mondo1926 No problem, and to be clear, it's not a book about testing but the concept of having tests before refactoring is talked about a chunk in it and helped me get into the right zone of thinking when I was newer to this stuff. I've still got plenty to learn. GL to ya.
@@SwashbucklingwithCode No worries man, thanks! Have a nice weekend!
Great stuff here! Love to see an CI-video from you!
First request I've had for it. I do think it would be worthwhile, but do you have any ideas of what you'd like to see covered in it?
More of a full set up from scratch type video, or just an overview of how to add certain actions/pipelines to your project?
And any specific CI operations, like testing or linting, etc.
@@SwashbucklingwithCode Full setup from scratch
Just started learning unit testing using jest. Thank you for this very helpful tutorial 🙌🏼
Awesome, good on you for getting into testing.
Thank you Jimmy! Pragmatic and pretty informative in depth journey!
This is so helpful! Thanks for the thorough explanation
Awesome, thank you for letting me know.
@@SwashbucklingwithCode I am getting a strange issue where it marks a template string literal such as:
const MY_URL = `${BASE_URL}/foo` as "else branch not covered".
Have you ever run into something like this? The BASE_URL is a const top-of-file String
@@lucasrmendonca My guess is that nothing is trying to use `MY_URL` without `BASE_URL` existing, though if it's declared in the same file outside of any function scope that does seem a bit strange to me.
@@SwashbucklingwithCode maybe this is getting transpiled by babel-jest into es5 or something so the coverage tool sees something in these lines that we don't? 🤔
Just learned something new :)
You Are super awesome and skillfull teacher. Thanks from Norway!
Thank you! I really like the explanation!
Sweet, ty.
you do good job Sir, thanks for the tutorial!
Thank you.
Very good job, you are an awesome teacher!
Thank you.
This is a very great tuotiral and a great paisen
Thank you
Ive implemented both these checks into my ci - global and folder level.
But 1 problem i face is that mine is a really large codebase - and I want to add a more granular check over coverageThreshold check - such that coverageThreshold module check will only fire - if a developer changed that file - not if doesn't include any change for that module.
example:
if i set coverageThreshold > "module - 1 - path" : {statements: 40}, "module - 2 - path" : {statements: 50}
then if some developer changes / adds code to "module - 1 - path" - only then fire the 40% check ?
is this possible ?
Do you do online teaching?
thank you jesus christ