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.
@@WebDevCody or you can create a function that will assert that the element is HTMLInputElement I do it, so I'm confident that element is a specific type.
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
Yeah, but knowing if a labeled changed isn’t a valuable test. We mainly care that a button clicked in the UI properly does the things it should in our system. Having integration tests to verify text or labels in our front end is a waste of time imo
@@WebDevCody True but at the same time we should also verify if the correct aria labels and other attributes are set on the rendered elements so I wouldn't disregard the component DOM testing completely.
Nice! I think that the first aproach (component testing) is nice and you're indrectly testing all the internal logic. It's nice because you can change the implementation and with the second aproach (testing the custom hook) you're testing internal implementation details. But, if this custom hook is reusable, this need to be tested in isolation from whatever the component uses. BTW, Could you upload a TDD real world example? I see a lot of "calculator" example, which is fine, but not a real world (and more complex) example. Thanks!
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.
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?
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
Yeah for sure, I do wonder why since checking by role and text content sounds like a brittle way to test. If someone changes the text of a button all your tests break? If you read the cypress guide they recommend using data-cy attributes to test with to allow non brittle tests
@@WebDevCody some would argue that’s exact what you want. Your tests are written so they break when something changes. Could help prevent typos or something. A text content change seems like a low effort change to a unit test anyway.
Honestly, it's extremely helpful just seeing another devs toolset and see their thought/work process. Really helps with broadening out knowledge and especially helps with your problem-solving skills to frontend problems. Thanks for the vid Cody,
![Noob To Max With DRAGON REWORK In Blox Fruits [FULL MOVIE]](http://i.ytimg.com/vi/LnBMOinoOvA/mqdefault.jpg)
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.
Typescript was complaining about the value attribute because the type HTMLElement was not narrowed down to HTMLInputElement.
Nice thank you, so maybe I just need to cast it then?
@@WebDevCody Yup exactly
@@WebDevCody or you can create a function that will assert that the element is HTMLInputElement
I do it, so I'm confident that element is a specific type.
@@Will4_U How would you do that assertion?
@@jlndev1017just throw an “as HtmlInputElement” at the end of the statement
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!
I’m still working on this MVC approach, but yeah I’m glad you see kind of where I’m coming from
The video sucks? No way bro. One of best I have watched. Very real and clear to learn.
best case scenario i search for a topic and web dev cody alrdy made a vid abt it
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
Yeah, but knowing if a labeled changed isn’t a valuable test. We mainly care that a button clicked in the UI properly does the things it should in our system. Having integration tests to verify text or labels in our front end is a waste of time imo
@@WebDevCody True but at the same time we should also verify if the correct aria labels and other attributes are set on the rendered elements so I wouldn't disregard the component DOM testing completely.
Nice! I think that the first aproach (component testing) is nice and you're indrectly testing all the internal logic. It's nice because you can change the implementation and with the second aproach (testing the custom hook) you're testing internal implementation details. But, if this custom hook is reusable, this need to be tested in isolation from whatever the component uses.
BTW, Could you upload a TDD real world example? I see a lot of "calculator" example, which is fine, but not a real world (and more complex) example.
Thanks!
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.
you seem to post vids on everything im curiuos about. cheer mate
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 ?
It’s in a repo called react-testing on my GitHub repo list
@@WebDevCody Thanks a lot!
Nice videos. I get the feeling that you're kinda abusing aria labels, just because you like to use them as test selectors ?
Yes I probably did in this video
What is the extension you are using for showing inline ts errors?
error lens
Thank you for your sharing. Could you make a video about setup/config mock data testing with firebase?
this was awesome, thanks!
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?
Selenium is more for e2e testing where
You actually test in different browsers, RTL is for component and integration testing.
There’s about as much test code as there is production code…is this typical for more complicated applications too?
Yeah, it depends on how important the feature is or your teams thoughts on testing.
9:50 because its a HTMLElement, u should do "input instanceof HTMLInputElement".
or "(await renderedApp.getByLabelText("todo-text")) as HTMLInputElement"
Thank you! I’ll try to remember that
can we make a video for Node Express API unit test ?
What's your Color theme & font name ?
Thank you for this
Good job babe!
I normally pass data-testid as a props to my component.
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
getByRole is the top priority to resemble a user
Yeah for sure, I do wonder why since checking by role and text content sounds like a brittle way to test. If someone changes the text of a button all your tests break? If you read the cypress guide they recommend using data-cy attributes to test with to allow non brittle tests
@@WebDevCody some would argue that’s exact what you want. Your tests are written so they break when something changes. Could help prevent typos or something. A text content change seems like a low effort change to a unit test anyway.
@@TheProcessor yeah, sure it’s low effort. I guess I’ll reconsider the idea
thank you
wow, so you literally have no idea what you're doing. making major changes while explaining something, waste of data
I never know what I'm doing
Honestly, it's extremely helpful just seeing another devs toolset and see their thought/work process. Really helps with broadening out knowledge and especially helps with your problem-solving skills to frontend problems.
Thanks for the vid Cody,
He obviously does. He said he didn't prepare for the video. Doesn't mean he doesn't know what he's doing.