Sometimes, httpbin is not enough, and you need your own custom HTTP server for testing.
Here's a small example on how to do that using the built in SimpleHTTPServer (thanks @noahsussman for reminding me).
If it won't be simple, it simply won't be. [Hire me, source code] by Miki Tebeka, CEO, 353Solutions
Thursday, October 25, 2012
Monday, October 15, 2012
http://httpbin.org
Sometimes you need to write an HTTP server to debug the client you are writing.
One quick way to avoid this is to use http://httpbin.org/. It supports most of the common HTTP verbs and mostly return the variables you send in.
For example (note the args field in the reply):
$ curl -i 'http://httpbin.org/get?x=1&y=2'
HTTP/1.1 200 OK
Content-Type: application/json
Date: Mon, 15 Oct 2012 21:50:27 GMT
Server: gunicorn/0.13.4
Content-Length: 386
Connection: keep-alive
{
"url": "http://httpbin.org/get?x=1&y=2",
"headers": {
"Content-Length": "",
"Connection": "keep-alive",
"Accept": "*/*",
"User-Agent": "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3",
"Host": "httpbin.org",
"Content-Type": ""
},
"args": {
"y": "2",
"x": "1"
},
"origin": "75.82.8.111"
}
One quick way to avoid this is to use http://httpbin.org/. It supports most of the common HTTP verbs and mostly return the variables you send in.
For example (note the args field in the reply):
$ curl -i 'http://httpbin.org/get?x=1&y=2'
HTTP/1.1 200 OK
Content-Type: application/json
Date: Mon, 15 Oct 2012 21:50:27 GMT
Server: gunicorn/0.13.4
Content-Length: 386
Connection: keep-alive
{
"url": "http://httpbin.org/get?x=1&y=2",
"headers": {
"Content-Length": "",
"Connection": "keep-alive",
"Accept": "*/*",
"User-Agent": "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3",
"Host": "httpbin.org",
"Content-Type": ""
},
"args": {
"y": "2",
"x": "1"
},
"origin": "75.82.8.111"
}
Friday, October 05, 2012
Cleanup After Your Tests - But Be Lazy
It's a nice practice to clean after your tests. It's good for various reasons like disk space, "pure" execution environment and others.
However if you clean up to eagerly it'll make your debugging much harder. The data just won't be there to see what went wrong.
The solution we found is pretty simple:
However if you clean up to eagerly it'll make your debugging much harder. The data just won't be there to see what went wrong.
The solution we found is pretty simple:
- Try to place all your test output in one location
- Nuke this location when starting the tests
Subscribe to:
Posts (Atom)