Declare tests_require and hook up 'test' command

This change allows the existing test script (test_requests.py) to be invoked via the standard setuptools test command. It also declares pytest as a test_dependency, so that it is installed on a test run, if not available.


Hey @koobs, thanks for the PR. Can I ask why you're adding this?


@sigmavirus24

TLDR: Best practice python packaging.

Longer version:

The 'test' command is the canonical method for running tests in Python land (ala make check for autotools projects) independent to how or what tests are run, or the tools that get used.

It also makes for a great downstream (users and os packaging) experience so we/they can QA, orthogonally to how an upstream might do 'development' testing (read: tox, travis, whatever)

For me (and FreeBSD), I have the following in the port for requests, so that I can QA updates and commit changes quicker with confidence.

```
regression-test: build
        @cd ${WRKSRC} && ${PYTHON_CMD} ${PYDISTUTILS_SETUP} test
```


If you want to derive *_requires *_require from requirements files, that's fine (and probably good so they're only referenced in one place).

In that case distinctions should be made between pre-release "development testing" and post-release testing requirements.

Additionally, distinctions between 'compulsory' requirements and optional test requirements (coverage, etc) in the same way extras_require is used for optional runtime dependencies.

For proper context and detail see: [cryptography Issue #764 comment](https://github.com/pyca/cryptography/issues/764#issuecomment-37152604)


I have no objection to this, though it's off the mainline development path and therefore runs the risk of getting overlooked if we ever change our test dependencies (unlikely).


Correct me if I'm wrong, (I posted my question right before going to sleep) but this doesn't actually run the tests with py.test. Don't we need a py.test setuptools command in the code and registered as `test_class` or something like that?

Further, doesn't `setuptools` still use unverified TLS to download the test dependencies when someone who doesn't already have `pytest` installed runs `python setup.py test`?


> Correct me if I'm wrong, (I posted my question right before going to sleep) but this doesn't actually run the tests with py.test. Don't we need a py.test setuptools command in the code and registered as test_class or something like that?

Probably

> Further, doesn't setuptools still use unverified TLS to download the test dependencies when someone who doesn't already have pytest installed runs python setup.py test?

I was told at DjangoCon EU that setuptools has been improved in that regard: @dstufft?


[This](https://pytest.org/latest/goodpractises.html#integration-with-setuptools-test-commands) seems like it's probably pretty relevant.


@Lukasa that command class is definitely what I had in mind. Without using py.test to _run_ the tests, only a fraction of them will be run since we have test functions that aren't attached to any test class that `unittest` could discover.

Also, regarding unverified TLS, I hope that setuptools has improved it but I'd be skeptical. It'd have to load certificates from somewhere and I doubt that it is also willing to vendor them. (The problem may be mostly alleviated on 2.7.9+ or 3.x, but that still leaves tons of people on systems without those versions in a lurch.) That said, I like being friendly to our downstream redistributors, so I'm happy to accept work to make `python setup.py test` work, but I think we need to actively discourage contributors from using it given the security concerns.


setuptools will (probably) use verified TLS if it's 0.7+, however it still will hit random websites on the internet which may or may not be HTTPS so it's certainly not "safe" by default. You can add a thing to your setup.cfg to tell setuptools to only accept pypi.python.org though (or to not install anything at all, just exist for the test dependency declaration).


This seems harmless, and certainly inline with the expectations of `setup.py` oriented workflows. However the fact that running `test_requests` directly won't result in a full run of our test suite (though it should), I'm going to close this.


@kennethreitz Where is the full test suite and how is it run?


@koobs it is all contained in `test_requests.py`, but it does not all use the unittest framework, instead relying on py.test to automatically pick up some functions and run them as tests. 

This should be fixed, in my opinion. I see no reason to be lazy just because we're using py.test.


It's not laziness: we _actively_ use pytest. We import helpers from it, we use its assertion style, the whole nine yards.


I'll create a separate PR for proper integration as per [pytest: Good Integration Practices](http://pytest.org/latest/goodpractises.html#manual-integration)