Add frontend request module wrapping fetch() #47
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The upcoming Calculator component will use this module to POST the calculator input and present the response. Also fixes a mistake in the `pnpm test-ci` command whereby I used the same ci/vitest.config.js twice in commit 3892b00 from #45. The second `vitest` command in that script will now use ci/vitest.config.browser.js as intended. --- Creating a separate module wrapping fetch() enables testing of all the request and response paths independently of any UI components. Since fetch() and its returned Response object are well specified and relatively small, it's relatively easy to use Vitest stubs to simulate fetch() interactions. This allows thorough testing of the fetch()-related logic without any complicated UI or setup or interactions, or even a backend server specifically for these tests. At the same time, the tests for each UI component sharing this module can can stub this module's methods. These tests can then exercise UI interactions more thoroughly without having to exercise and account for fetch()-related logic paths. Of course, we'll have our end-to-end Selenium WebDriver tests to validate frontend and backend interactions. These will also validate if the test doubles for fetch() in particular are congruent with production implementations. But we won't need as many of those tests trying to validate too many details if we've designed testable code and enough good smaller tests. That's the idea behind the Test Pyramid: A balance of tests of different sizes for different purposes.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The upcoming Calculator component will use this module to POST the calculator input and present the response.
Also fixes a mistake in the
pnpm test-cicommand whereby I used the same ci/vitest.config.js twice in commit 3892b00 from #45. The secondvitestcommand in that script will now use ci/vitest.config.browser.js as intended.Creating a separate module wrapping fetch() enables testing of all the request and response paths independently of any UI components. Since fetch() and its returned Response object are well specified and relatively small, it's relatively easy to use Vitest stubs to simulate fetch() interactions. This allows thorough testing of the fetch()-related logic without any complicated UI or setup or interactions, or even a backend server specifically for these tests.
At the same time, the tests for each UI component sharing this module can can stub this module's methods. These tests can then exercise UI interactions more thoroughly without having to exercise and account for fetch()-related logic paths.
Of course, we'll have our end-to-end Selenium WebDriver tests to validate frontend and backend interactions. These will also validate if the test doubles for fetch() in particular are congruent with production implementations. But we won't need as many of those tests trying to validate too many details if we've designed testable code and enough good smaller tests. That's the idea behind the Test Pyramid: A balance of tests of different sizes for different purposes.