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
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
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
On Thursday, 26 July 2018 04:50:58 UTC+8, Melvyn Sopacua wrote:
>
> On dinsdag 24 juli 2018 04:21:07 CEST Kum wrote:
> > Is there a way to
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
--
You received this message because you are subscribed to the Google Groups
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
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".
On Tuesday, 24 July 2018 04:21:07 UTC+2, Kum wrote:
>
> Is there a way to
Is there a way to prevent people from accidentally doing so?
On Monday, July 23, 2018 at 7:39:27 AM UTC-4, Jason wrote:
>
> 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.
>
--
You received
On maandag 23 juli 2018 17:23:20 CEST chuck.horow...@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
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?
On Monday, July 23, 2018 at 8:22:17 AM UTC-4, Melvyn Sopacua wrote:
>
> On maandag 23 juli 2018 13:39:27 CEST Jason
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
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.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop
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
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this
12 matches
Mail list logo
