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

Reorganize frontend modules and other files #45

Merged
merged 1 commit into from
Dec 15, 2023

Conversation

mbland
Copy link
Owner

@mbland mbland commented Dec 15, 2023

strcalc/src/main/frontend was becoming a bit cluttered. This should make things a bit more clear and manageable.

strcalc/src/main/frontend was becoming a bit cluttered. This should make
things a bit more clear and manageable.
@mbland mbland self-assigned this Dec 15, 2023
@mbland mbland merged commit b44c22c into main Dec 15, 2023
3 checks passed
@mbland mbland deleted the reorganize-frontend-modules branch December 15, 2023 21:33
mbland added a commit that referenced this pull request Dec 16, 2023
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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant