[go: up one dir, main page]

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Another way to condition a response #55

Open
irsooti opened this issue Jul 13, 2024 · 2 comments
Open

Another way to condition a response #55

irsooti opened this issue Jul 13, 2024 · 2 comments

Comments

@irsooti
Copy link
irsooti commented Jul 13, 2024

Description

In my common use cases, I don't have the ability to add a search param to do a conditional response.

Consider this silly scenario:

test('something', () => {

const user = getUser() 
expect(user).toBe(someCondition)
})

The function getUser contains a fetch request that retrieves users.

In the case of a happy path (200), the handlers created using fromOpenApi are fine. Now, let's repeat the same test using another type of response, for instance a 400 one.

According to the documentation, I should add a search parameter response to retrieve the response coupled with the status code, but as shown in the scenario, I can't just add the parameter because it's a detail I don't have control over (it could be something from a package, or a prebuild sdk with all the http calls inside).

Alternatives

Maybe it could be easier to consider some utility to control the status code of the msw handlers, I do not have a good idea to propose but conceptually is something like:

import { sourceryFnThatEditResponseCode } from '@msw/source'

test('something', () => {
// intercept '/the-endpoint-to-sent-in-400' and reply with 400 so retrieve the response based on 400 schema
sourceryFnThatEditResponseCode(...)

const user = getUser()

expect(user).toBe(someCondition)
}

wdyt?

@kettanaito
Copy link
Member

Hi, @irsooti. Thanks, this is a great concern!

The search parameter approach is mainly meant for triggering different responses in the browser, and we are working on the improved browser support for fromOpenApi.

I think #57 is going to solve your problem though! You will be able to trim down the operations (and, hopefully, their responses) during the test setup.

@irsooti
Copy link
Author
irsooti commented Aug 1, 2024

Hi, @irsooti. Thanks, this is a great concern!

The search parameter approach is mainly meant for triggering different responses in the browser, and we are working on the improved browser support for fromOpenApi.

I think #57 is going to solve your problem though! You will be able to trim down the operations (and, hopefully, their responses) during the test setup.

NICE! I'll wait it be documented and merged then.

We ended up to create a middleware to add the search params as temporary solution

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants