we use translation keys for picking an element in test file. generally translation keys wont be changed, but actual words may change. but it wont break tests because t('some.translation.key') will always same in virtual rendering.

best case scenario i search for a topic and web dev cody alrdy made a vid abt it

Typescript was complaining about the value attribute because the type HTMLElement was not narrowed down to HTMLInputElement.

Honestly I agree man. I kinda like the approach you have here. The MVC stuff was a little harder to understand, but I feel like this video made more sense!

Great video, I definitely agree with your stance on testing the state logic in isolation. Testing complex components via DOM can get really tedious for little value in my opinion.

I think, and forgive me if I'm wrong, that you slightly missed the point of integration/unit tests. At one point near the end of the video, you are saying "What if you change an aria label, or something, etc". That is one of the main points of testing. When you change something, your test is supposed to fail, and if it does, it's on you to decide if that was suppose to happen, and you have to update your test, or if it was an accident, and you revert your code. That is the primary purpose of testing. So if at one point in time, you change your tag's attribute, or you change anything in relation to that, you absolutely want your test to fail. If it doesn't, then your test is useless. In simple words, you shouldn't be writing tests as you are writing your code. Tests exist so they can notify you that something in your code has changed, and at that point, you have to decide if that change was intentional, aka, update the test to reflect that, or if its a regression, aka, fix or revert the code. Cheers

The video sucks? No way bro. One of best I have watched. Very real and clear to learn.

you seem to post vids on everything im curiuos about. cheer mate

This is exactly my thought on Testing. It doesn't have to be everything, just the most important part. Extracting the logic out of the component is more sensible to me rather than testing the whole component which is tedious, brittle, and hard to read.

this was awesome, thanks!

Thank you for this

Good job babe!

Hi, thanks for your videos, they all are really informative. Do you mind to share this little project to see how you wrote your hook ?

Thank you for your sharing. Could you make a video about setup/config mock data testing with firebase?

Nice videos. I get the feeling that you're kinda abusing aria labels, just because you like to use them as test selectors ?

Hey man, I love your react videos they're really helpful ❤. Can you maybe do a video about Vite or Webpack configs that you use? I'm looking for some helpful configs that I can use for production which reduce the bundle size and optimizes performance for my react app. I've used some configs for production before but I wasn't using any frameworks for those projects and they were just native Js applications but somehow I'm having difficulties finding the right configs for my react applications. Thank you

thank you

I normally pass data-testid as a props to my component.

Thank you. I know about testing-library now. I'll read it over. I've seen people use mocha and selenium JavaScript. Is this library built only for react and more preferred over selenium?

9:50 because its a HTMLElement, u should do "input instanceof HTMLInputElement".

What is the extension you are using for showing inline ts errors?

can we make a video for Node Express API unit test ?

There’s about as much test code as there is production code…is this typical for more complicated applications too?

What's your Color theme & font name ?

getByRole is the top priority to resemble a user

wow, so you literally have no idea what you're doing. making major changes while explaining something, waste of data