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

361 fix home specs #373

Merged
merged 11 commits into from
Feb 14, 2024
Merged

361 fix home specs #373

merged 11 commits into from
Feb 14, 2024

Conversation

alishaevn
Copy link
Contributor

@alishaevn alishaevn commented Feb 8, 2024

Story

fix the 7 home specs locally. they will still fail in ci due to configuration. (ref: #378)

Screenshots / Video

image

Testing

  1. pull this branch
  2. ensure you have all of the environment variables in the env property of "cypress.config.js" set up.
  3. run yarn cypress:e2e
  4. choose the "home" test

`req.reply()` was not returning an empty response, it was returning the
actual response from the server. this led to the "loading" state being
present momentarily before the actual response was returned. we are now
forcing the loading state to remain, as the mock intends.
made the cypress config file more dynamic. it also will allow us to
correctly intercept api calls in our `customApiIntercept` command.

update the "featured services list is loading" test check that we in
fact have 3 placeholder items, as the description states.
Copy link

vercel bot commented Feb 8, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
webstore-staging ✅ Ready (Inspect) Visit Preview 💬 Add feedback Feb 12, 2024 9:03pm

@alishaevn alishaevn linked an issue Feb 8, 2024 that may be closed by this pull request
1 task
changed up the specs to fit the flow of the home page. also moving two
specs from the browse page to the home page since that's where the
requests originate from.
although we were catching the error in `#fetcher`, we weren't returning
it as an error. it was being returned to the caller as the `data` value.
this means none of our `isError` checks for GET requests were working
properly.
with this commit, we're throwing the error so that we are handling it
on the view correctly.
we're testing for an invalid access token now.
the `customApiIntercept` command is also simplified.
also further simplified the `customApiIntercept` function.
@@ -11,6 +11,7 @@ export const fetcher = (url, token) => {
.then(res => res.data)
.catch(error => {
Sentry.captureException(error)
throw error
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

without this, we are only getting the placeholder cards on the homepage, instead of the error notice.

if we use return instead of throw, then the useSWR hook would incorrectly get the error as the data property:

{
  data: <AxiosError...>,
  error: undefined
}

@alishaevn alishaevn merged commit 60b689c into main Feb 14, 2024
5 of 6 checks passed
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

Successfully merging this pull request may close these issues.

fix "home" e2e specs
2 participants