-
-
Notifications
You must be signed in to change notification settings - Fork 9.7k
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
Prevent unexpected network calls in tests #16903
Prevent unexpected network calls in tests #16903
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excuse the nit-picking: LOVE this approach, really clever idea and will be super useful!
allow(Homebrew::API::Formula).to receive_messages(all_aliases: {}, all_renames: {}) | ||
allow(CoreTap.instance).to receive(:tap_migrations).and_return({}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be nicer to ensure some correct files are written on disk instead of mocking.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Out of laziness, I'm going to skip that for now.
I think this check can actually be much much simpler. All of the network calls in There are other places in the codebase where network calls could potentially happen in tests like the Edit: It's not simple to check in |
0ad15b6
to
1adddc5
Compare
Any test that is not tagged as :needs_network and that makes a call to an unapproved method in the `Utils::Curl` module will raise an error unless that method gets mocked somehow. tests: add exceptions for tests that use curl to download local files These are acceptable ways to use curl in local, non-network tests. For those edge cases we allow you to bypass the check with :needs_utils_curl.
These were found with the Utils::Curl check and just turning off the network on my computer and running the entire test suite.
1adddc5
to
ad35db4
Compare
@MikeMcQuaid Thanks for the feedback! I was able to simplify the check further as explained above along with using your suggestions for the error message and the name of the escape hatch which is now I also removed the changes to the two tests which didn't need the network anymore based on the bug fix in |
Or make it so that it always returns e.g. |
This sets the HOMEBREW_NO_INSTALL_FROM_API environment variable to prevent the selected tests from using the API. We will need this as we transition to having the API be enabled by default when running the tests but it's also nice as a sanity check with the :needs_utils_curl scope in a few places.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great once s/:needs_github_api, //g
is done, sorry/thanks!
836a26b
to
74aea8e
Compare
Thanks @apainintheneck! |
brew style
with your changes locally?brew typecheck
with your changes locally?brew tests
with your changes locally?This implemented a crude check for unexpected network calls in tests that are not tagged
:needs_network
. Basically, it raise an error ifany methodthe.curl_executable
method in theUtils::Curl
module is referenced and is not stubbed. This works most of the time and it did help me uncover a few tests that were making network calls when they shouldn't have been. Of course, sometimes we know that the network calls we're going to make are all to the local filesystem and in that case there is an escape hatch you can use with the:allow_utils_curl
:needs_utils_curl
tag.As written this works well with the current codebase but does clash a bit with the API mocking ideas found in #16895. It should be possible to override the checks in the test suite when we add some sort of mock API helper though.
I'm marking this as discussion to see if people think this is a good general idea and are okay with the implementation.
CC: @Bo98 @reitermarkus
Changes: