Add a true integration test that actually executes Bundler #41
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.
Before, our CLI tests were doing a significant amount of stubbing to avoid making external calls to Bundler commands. This limited the value of these tests. It also made them tedious to write, and required behind-the-scenes knowledge of when and how the lower-level code called out to Bundler.
In this PR, I refactored the existing CLI tests so that the stubbing is done at a higher level: at the
Reporter
API. This makes test setup easier while still allowing us to write tests to cover various CLI edge cases, like error handing.For the primary, "happy path" case, I've created a
CLIIntegrationTest
. This runs the actualupdate-interactive
executable viaOpen3.capture3
, so every layer of the code base is exercised. Most importantly, Bundler commands themselves are actually executed.The integration test confirms that when a gem is selected to be updated, the update really happens. It does this by inspecting the
Gemfile.lock
to see that the gem version was changed as expected.I also updated the
mocha
configuration to make stubbing more strict going forward.