Test: Write test ensuring leading 0's for zip code are not removed

[jakeleboeuf]

Describe your PR

We want to ensure any zip with a leading zero doesn't get stripped before sending to the Google API. So 02215 should stay 02215 and not become 2215 when sent to search.

To do this, I'm asserting 2 things: 1) The XHR Request to the Google Geocode API 2) The redirect url contains location=<LEADING_ZERO_ZIP>

Fixes #215

Pages/Interfaces that will change

• /businesses (Tests only)
• /allies (Tests only)

Screenshots / video of changes

https://www.loom.com/share/c8653ef66970469b83fcdc390ea11059

Steps to test

1. $ npm run test:e2e
2. Look for ✅

Additional notes

Zip code search is not currently implemented for the /allies page, so those tests are not included in this PR

[netlify[bot]]

Deploy preview for rebuild-black-business processing.

Building with commit b01f3b663d87c94904ac72c029a103a52078ebf1

https://app.netlify.com/sites/rebuild-black-business/deploys/5f075aeb236e3e00086f94d3

[magnificode]

@racedale - Any input here sir? I ran through the code here myself and things look pretty solid!

[racedale]

@magnificode yep looking good to me too! Just curious on why the netlify build failed 🤔 I'll clear cache and retrigger the build

---

Edit: Seems to tend to be a gatsby build issue with whatwg-fetch https://github.com/mongodb/stitch-js-sdk/issues/381

Wondering if there's an easier way to solve this?

[jakeleboeuf]

I’ll track this down and find a solution in the morning 🤙

[jakeleboeuf]

@magnificode:

Seems to tend to be a gatsby build issue with whatwg-fetch mongodb/stitch-js-sdk#381

Wondering if there's an easier way to solve this?

I've removed the import 'whatwg-fetch'; statement from the app (and moved it to import the polyfill during the cypress setup) which I think will resolve the Gatsby build issue. I'm not able to reproduce when running npm build locally, so kinda shooting in the dark 🤦