we enabled webmock over the weekend in core tests. This means that everytime a unit, functional, integration or any test in core attempts to make a HTTP or HTTPS connection it will be disallowed and test will fail with handy explanation of what happened and how to stub the request.
However, do not use
stub_request method directly and prefer stubs/expects from mocha library on top of our Proxy API classes. We tend to connect to external services via common API which is a good design pattern to follow. There are places where
stub_request might be appropriate, but we should minimize those - there are currently two uses in the whole codebase.
There is one exception - localhost and 127.0.0.1 addresses are whitelisted, because integration tests use them. This means that when writing tests prefer some dummy hostnames to localhost so we error out early. I’ve seen many dummy hostnames in the codebase, the golden rules are:
- do not use localhost or 127.0.0.1
- use existing domain but non-existing host which does not resolve fast (e.g.
- prefer mocha stubs to webmock stubs
I have a hope that this will bring number of random failures to minimum, I fixed several tests which were actually doing requests (which failed). Few tests were actually incorrect - those expecting a failure of different kind. We will see if there are less random failures. Thanks.
More info about webmock (keep in mind we utilize it rather to fail early than using the stubbing mechanism):