On Thursday, February 28, 2013 23:51:00 Oleg Pudeyev wrote:
> Hi list,
>
> I have been working on making pycurl Python 3-compatible. In the
> process of doing that I realized that I needed tests that did not exist
> (e.g., I could not find a test that simply made a GET request with
> nothing else). Therefore I had to start writing a test suite in a
> unittest-ish format.
>
> That is when the question of what the test suite could use, and
> subsequently depend on, came up. As pycurl is an http client, an http
> server is needed to test pycurl against it. Implementing such an http
> server and managing its lifetime in the tests requires greatly varying
> amounts of effort depending on which libraries are used.

pycurl is not only HTTP client, it supports over 20 protocols. Nevertheless,
testing it against an HTTP server sounds like a great improvement against
status quo.

> 1. Python standard library only: server is SimpleHTTPServer based, is
> started and stopped in setUp/tearDown methods for each test method.
> This option requires no dependencies, but is most laborious and also
> slowest due to repeated setup/teardown.
>
> 2. Use nose (https://nose.readthedocs.org/en/latest/) for running
> tests. This in particular allows for module-level setup and teardown
> code, which means the http server will be started and stopped once per
> test module rather than once per test method.
>
> 3. Use a framework for writing the http server to test pycurl against.
> I have had good results with bottle (http://bottlepy.org/docs/dev/).
> This dramatically reduces the time needed to write the http server.

I am fine with any of the above, although I have no first-hand experience
with any of them. The nose package seems to be better available on some
more ancient distros.

> 4. Use an existing test http server. I only came across these recently,
> but https://github.com/Lispython/httphq looks like a fairly
> comprehensive implementation. The upside is pycurl does not need to
> implement its own test server. The downside is the test http server may
> do more than pycurl needs and have further dependencies of its own. In
> particular, httphq requires tornado from what I see.

Is this going to be packaged for the distributions that pycurl is shipped
with?

> 5. Use an existing test http service (i.e. software from #4 hosted by
> someone on the Internet). I am including this for completeness, but I
> believe that offline development is essential and thus requiring an
> Internet connection to run the test suite is a no-go.

Yes, this would kill nearly all the use cases the test-suite is intended for.

Kamil
_______________________________________________
http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-and-python
Received on 2013-03-02