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

Phone number does not validate in React Testing Library test #347

Closed
jamenamcinteer opened this issue Jun 5, 2020 · 5 comments
Closed
Assignees
Labels

Comments

@jamenamcinteer
Copy link

Expected Behavior

If the phone number entered in the component is valid, the isValid property should be true when running React Testing Library tests (tests should match what is experienced in the browser).

Current Behavior

In the browser, when a valid phone number is entered in the component (or passed in as the defaultValue), the isValid property as seen with onPhoneNumberBlur, for example, is true and the phone number is properly validated. However, when the same behavior is recreated in a test using React Testing Library, the validation fails and the phone number is considered invalid even though it should be valid.

Steps to Reproduce

GitHub repo: https://github.com/jamenamcinteer/react-intl-tel-input-rtl-validation
Repl.it demo: https://repl.it/repls/WellmadeCompetitivePyramid

  1. Run yarn start
  2. Click into the phone number field and then click out of it. Observe that the message Phone number is valid appears.
  3. Run yarn test
  4. Observe that the test fails as the message Phone number is valid never shows up. See App.test.js for the test code and App.js for the app code.

Environment

  • Version: v8.0.2
  • Browser: all
@jamenamcinteer
Copy link
Author

A little more info: when I try printing the values received by onPhoneNumberBlur in the browser vs RTL tests, the fullNumber value in the browser includes the country code but in the tests it is missing the country code. In the provided example, the browser fullNumber is +1 234-567-8901 while the fullNumber for the test is (234) 567-8901.

@mcataford mcataford self-assigned this Jun 10, 2020
@mcataford
Copy link
Collaborator

Hi @jamenamcinteer!

Thanks for the thorough report! I'm digging into this a bit this weekend to see if I can get a grip on why it happens. If it's something you'd be interested in tackling, let me know!

@mcataford mcataford added the bug label Jun 13, 2020
@mcataford
Copy link
Collaborator

I dug into it a bit and was able to isolate the issue to an asynchronous import to the library that handles the "core" of phone number validation / manipulation. During initialization, it will use import(...) to get it to populate window, which is then used throughout for validation. This is obviously not ideal because it leaks things into window and then relies on the integrity of what's in there even though it has very little control over it. In the context of RTL, it looks like the test proceeds with or without the initialization step, so window isn't necessarily populated when your assertions are run.

I'm going to look into making that dependency a synchronous import and cleaning it up, but this might require some time given that it involves some rewriting of another package and/or some research into an alternative.

In the meantime, I've found that "shortcircuiting" the async import by importing it yourself in your test suite solves the issue. This is a crude workaround. You could also figure out an dirty wait(...) trick to wait until the window.intlTelInputUtils object is populated, but it feels worse than including the dependency yourself.

You can add libphonenumber-js-utils as a devDependency to your project and import it for its side-effects to resolve the issue:

import 'libphonenumber-js-utils`

test(...)

Let me know if it solves the issue on your end, it seemed to work on mine. Anyhow, I'm starting work on addressing the root cause so that this workaround isn't needed longer than it needs to be.

@jamenamcinteer
Copy link
Author

Hey @mcataford! Thank you so much for looking into this. I tried the workaround in my project and it works perfectly. I appreciate all your help with this!

@mcataford
Copy link
Collaborator

Glad it worked out!

Since the root cause is documented in #348 and we've got a workaround for your use case, I'll go ahead and close this issue for now. Don't hesitate if you find out any more wonky interactions with RTL!

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

No branches or pull requests

2 participants