I'm starting to come around to liking React Testing Library

Рет қаралды 4,830

Жыл бұрын

I think I used to talk poorly about it a long time ago, but it's making sense to me now finally.
🤖 SaaS I'm Building: www.icongeneratorai.com/
💬 Discord: / discord
🔔 Newsletter: newsletter.webdevcody.com/
📁 GitHub: github.com/webdevcody
📺 Twitch: / webdevcody
🤖 Website: webdevcody.com
🐦 Twitter: / webdevcody

Пікірлер: 18

@darialyphia Жыл бұрын

Wrap your trpc calls in custom hooks and just mocks those hooks. Decoupling will make it easier to test and unclutter your component code. It will also remove the need for all those providers in your test setup

@WebDevCody Жыл бұрын

So don’t even try the mock service worker stuff?

@darialyphia Жыл бұрын

@@WebDevCody it's good for integration testing imo. For unit test, rethinking your architecture a bit and encapsulating third party libs and using context providers work great, because in testing you just wrap into a mock provider and you're good. With trpc it's a bit awkward, since it uses react-query under the hood, you don't want to start mocking that...which is why is usually go for the lower level .query() and .mutate() and wire it up with react-query manually. No need to mock react-query, just the fetching function. This does make the code a bit more boilerplatey, but as you probably know thisis often the price to pay when you want to have a smooth experience with testing without mocking the entire earth

@NicolasVegaTerrazas Жыл бұрын

@@darialyphia I love this idea actually, I dont mind the extra boilerplate. Do you have a gist or some resource to see how your code looks like when doing this ? I have an idea more or less, but worth to ask :)

@shakapaker Жыл бұрын

@@darialyphia do you have any code example? would be grateful for that

@huge_letters Жыл бұрын

Regarding the boilerplate with trpc and else - I've recently used Cypress component testing, there I could just define a mount method which by itself would include all the required providers for my components(like redux store, router provider etc), and then in tests themselves I just use the mount method and it works.

@JonMartins Жыл бұрын

For styling tests the best approach is to do snapshot testing. Good content by the way

@AustinMarlar Жыл бұрын

I would highly recommend either creating a custom input component or a wrapper for your inputs that has a role (like input-alert or something) and a `data-alert-type=error`. The cool thing about that is that you can base your styles off of data-alert-type so all you have to do in your tests is check for that data attribute and you know that whatever styles are appropriate are being used. The test for the input just checks that the data attribute is set to error (expect(element).toHaveAttribute('data-alert-type', 'error')). You can have a test for your special input/wrapper component for the actual styles (either snapshot or checking classes like you do here). Then, if the styles change, you only change it for ONE test. Also, only one component has to change to carry all changes across the whole app. The point it, checking the classes like that is going to be a maintenance nightmare. Also, fragile tests (which you point out). So, give your tests a generic mechanism to determine state, and base your styles off of that state. EDIT: MSW is awesome, highly recommend :)

@WebDevCody Жыл бұрын

Good suggestions! I think I need to display error messages under the inputs when errors occur anyway, so I should just check to the existence of those error spans and call it a day

@donnyroufs551 Жыл бұрын

Don't you think that asserting whether a class has been added is the wrong way around? What if I decide that the border is being added through inline styles? The behavior is still the same but the test breaks

@WebDevCody Жыл бұрын

Yeah, I think I did say this approach is a bit brittle. I could instead add a data attribute called hasErrors? What solution do you suggest?

@donnyroufs551 Жыл бұрын

@@WebDevCody That solution also sounds flaky to me since you are introducing a design decision for testability. I would probably assert against its actual computed style whether it has the border. However, my fe testing is nowhere to be seen. I mean I have done it for work but I have no strong opinions nor enough experience to know what backfires and what not

@WebDevCody Жыл бұрын

@@donnyroufs551 I think my issue is my ui isn’t accessible with errors. There should be error text under all forms so people with screen readers can highlight and get error text read to them, and I didn’t do that. The proper test would be verify error text is displayed under each form group instead of checking for a border now that in revist this