Prevent Django tests from accessing internet (except localhost)

[Kum]

Hi,

Is there a global config I can enable to prevent any Django tests in a project from accessing the internet (i.e., only allow network calls to localhost) ?

Thanks

[Jason]

you shouldn't be accessing external services with your tests, you should mock or patch them with expected responses/failures and test based on that.

[Melvyn Sopacua]

On maandag 23 juli 2018 13:39:27 CEST Jason wrote:
> you shouldn't be accessing external services with your tests

Non-sense. Part of interacting with a remote API is making sure it works and
they didn't change anything (trust me, there's plenty of API's that change
without changing version numbers).

As for a global setting: no there isn't one. Your tests should have a switch
of their own if you're worried about that.

--
Melvyn Sopacua

[chuck.h...@packetviper.us]

Hi Kum,

I think Melvyn's suggestion is a good one.  Is there any reason you couldn't do:

 

import DEBUG from yourapp.settings

And then check against that for your testing?

[Melvyn Sopacua]

On maandag 23 juli 2018 17:23:20 CEST chuck.h...@packetviper.us wrote:
> Hi Kum,
>
> I think Melvyn's suggestion is a good one. Is there any reason you
> couldn't do:
>
>
> import DEBUG from yourapp.settings
>
>
> And then check against that for your testing?

Here's some code I used in a test:

class KvkApiTester(Testcase):
def skip_live_tests(self):
api_config = getattr(settings, 'KVKAPI', dict())
if not kvk_config or kvk_config['live_tests'] is False:
raise self.skipTest('live tests disabled or no KVKAPI configuration)

def test_api_key(self):
self.skip_live_tests()
... # actual tests

That way you know why tests are not running.

[Kum]

Is there a way to prevent people from accidentally doing so?

[Derek]

Have a switch that is set to OFF by default (then your tests will switch to using a mocked approach) and then have test that can only be be run with direct access to the API if you deliberately set it ON.

No "accidents".

[Gene]

There is no such config, but you can make it through socket interface mocking 

https://stackoverflow.com/questions/18601828/python-block-network-connections-for-testing-purposes

You can also split all tests into two groups:

- unit tests - should run without internet and all required requests should be mocked

- integration tests - should run with internet as in production system

For integration tests you can use decorator skipUnless  (from unittest import skipUnless)

You can have settings_test.py and settings_integration_tests

for example, there can be a parameter in settings 

INTEGRATION_TESTS = True (or False in unit test settings)

and then, test functions can be decorated like

@skipUnless(settings.INTEGRATION_TESTS)

[Melvyn Sopacua]

On dinsdag 24 juli 2018 04:21:07 CEST Kum wrote:
> Is there a way to prevent people from accidentally doing so?

To prevent network access, there are firewalls. Django isn't the thing for it.

--
Melvyn Sopacua

[Gene]

Preventing code from using networking is a common approach for unit tests

Firewall is a completely different story and has nothing common with this matter

[Gene]

By the way, another approach which is quite convenient is to run unit tests in docker during build stage (you will need to use settings with sqlite)

Quite convenient in combination with pipeline or CI framework, for example bitbucket pipelines

Or even on localhost

On Monday, 23 July 2018 19:04:48 UTC+8, Kum wrote:

[Melvyn Sopacua]

On donderdag 26 juli 2018 02:35:01 CEST Gene wrote:
> Preventing code from using networking is a common approach for unit tests
> Firewall is a completely different story and has nothing common with this
> matter

It does, because he's looking for a catch-all button. If you read the entire
thread you'll see we've offered several times, several strategies for
different approaches for unit tests.

But he's looking for the equivalent of "turning off the main water line" -
and that's a firewall or sandboxes / virtual machines without network routing.

Django has absolutely no way to do that and cannot, because there's no telling
what 3rd party apps do (not that python has such a switch or even C).

--
Melvyn Sopacua