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 ?
