[Test/e2e] Add a mechanism to stub binaries #3485
Open
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.
This PR is an initial implementation to be able to stub binaries during e2e tests.
The current
e2e/api.spec.ts
tests are not really doing an e2e test: those tests are testing that thewindow.api
functions return a version for each binary but are not really testing the boundaries of the app from the user point of view. They are more like an API test.With this PR we can test navigating Heroic as a user would, going to Settings > Advanced where the versions are displayed, and we can now stub the binaries to test different outcomes. The current tests only stub a single stdout value, but the subbing supports setting a response Promise if we want to do something more complex to mimic a download progress for example?
I also added a few
if (process.env.CI === 'e2e')
guards in commands that were performing external requests, we shouldn't do that (and eventually we should also add a method to stub those to be able to test different scenarios).Use the following Checklist if you have changed something on the Backend or Frontend: