Install unit testing tools and write `LocationSearch` unit tests

[TylerMatteo]

The goal of this Issue is to familiarize ourselves with the libraries we will use for front end unit testing in React apps. The two main libraries we want to use for this are:

• Jest - A test runner that allows us to write structured tests with a robust expect API
• React Testing Library (RTL) - Part of the @testing-library family of packages, RTL gives us a handle tool belt for writing user-centric unit tests. It is what we use inside of our Jest tests to do things like DOM manipulation and selection

There are two primary goals for this Issue.

• [x] Install and configure Jest and RTL in ae-zoning-map-poc. See their respective docs for instructions. Note that we should follow instructions for Typescript where given.
• [ ] Write a suite of unit tests for the <LocationSearch> component. This should test at least the following:
  • [ ] That the component correctly displays the list of boroughs from useFindBoroughs in the borough <Select>. This should require mocking that hook's return value
  • [ ] When a user selects a borough, block, and lot, then clicks the "Search" button, test that the handleBblSearched prop passed to the component is called with the correct arguments. This will likely involve spying on that prop and using Jest's toHaveBeenCalledWith method.

Part of this work will involve exploring how best to mock code that fetches data from an API, such the API call triggered by useFindBoroughs. We could simply mock return values for that hook based on what we expect it to return, but there may also be some tooling that can do that for us based on the API's OpenAPI specification. Kubb is a tool we already use in this repo to code-gen the hooks themselves based on the OpenAPI spec. Kubb also has a plugin for Mock Service Worker - a popular API mocking library. As part of this Issue, we should also explore using that tool chain for generating API mocks. If this work out, we can add these goals to the AC for this Issue

• [x] Install the dependencies for MSW and MSW Kubb plugin and update kubb.config.ts to include it
• [x] Regenerate the code in /generated to include the generated MSW code
• [ ] Use that newly generated code in the LocationSearch unit tests to mock the API call triggered by useFindBoroughs

Once all of the above is done, put a PR with these changes for review. You may also create a new Discussion about front end unit testing to document and get feedback on any issues you had, questions about general approach to unit testing, etc.

[TylerMatteo]

@bmarchena here's that unit testing Issue I owed you. If you want some help when you get to the parts involving Kubb, hit up @TangoYankee. Tim - I'm hoping you can block out a bit of time to help Bryan with some of the Kubb set up and how best to incorporate MSW into unit tests where appropriate.

[TylerMatteo]

@bmarchena - @TangoYankee ran into some issues setting up Jest for the repo template that led us to favor Vitest. It's very similar to Jest but I think it would be worthwhile for us to switch over using it in the PoC repo as well. The feedback I left on your pull request about what to actually test should still be relevant. You can make a fresh branch to set up the repo with Vitest instead of Jest. Tim is available to help with with the installation and set up, and I suggest you two sync up today so Tim can show you how he did it in the repo template. Once you have the set up done, you can continue with writing tests per my feedback on your existing PR.

[bmarchena]

@TylerMatteo I added a small test to my working branch to make sure that the handler is being called when we click on the Search button in the Location Search component. I ended up using a mock function and handing that to the component as a prop and just checking to see that it was called. Let me know if you have any thoughts

[bmarchena]

@TylerMatteo You mentioned that we'd be splitting the boroughs test into another issue this morning but could you clarify what you meant by "making the last test work?" I think that in order for us to test the submit functionality the way we'd like (ensuring the function is called with the certain params) using toHaveBeenCalledWith we'll need to resolve that other issue first but maybe you had another implementation or idea in mind

[TylerMatteo]

Hey @bmarchena, given the time we've sunk on this so far, I'd rather you focus on the data orchestration work or the Storybook testing over this. I'll self-assign and see if I can't refactor the component in a way that lets us write some tests now and revisit the issues we're having integrating MSW.

[TylerMatteo]

I'm having some trouble rebasing @bmarchena's branch for this but otherwise we can merge in that branch with the failing tests disabled for now. We should revisit how to take advantage of MSW in unit tests.