HTTPretty 0.5.8 – mock HTTP requests in Python at the socket level | Hacker News Reader

HTTPretty 0.5.8 – mock HTTP requests in Python at the socket level

falcao.it

58 pointsgfalcao8 comments

I really, really like this. I will definitely use it at work and for my own personal projects.

I will admit, though, that I'm not a fan of the rspec-like broken English. I hate to bikeshed here, because I really do love this idea, but these are just the opinions of myself, nobody particularly important. Feel free to disregard them :)

Some find the following to be more readable by the fact that it has more English words:

    expect(HTTPretty.last_request).to.have.property("querystring").being.equal({
    ...

It is in fact easy to read, but I find it very hard to write. The fact that the commands are so close to English throws me off more, because there are so many ways to construct a "sentence" that "sounds right" but is not equal to the desired command.

    expect(HTTPretty.last_request).to.have.property("querystring").being.equal({
    expect(HTTPretty.last_request).to.have("querystring").being.equal({
    expect(HTTPretty.last_request).to.have.property("querystring").equal({
    expect(HTTPretty.last_request).to.have("querystring").equal({

I would personally prefer something like the following. Even though it isn't as friendly to non programmers and doesn't read like English at all, it's hard to get wrong.

    expect(HTTPretty.last_request).querystring.equals({

I obviously do not know enough about the project yet to know if there are so many potential properties (such as 'querystring') that the .property method became a structural necessity as opposed to syntactical sugar. If there aren't so many properties, I'd just hardcode them into methods/properties.

Once again, I really look forward to using this project, and it's perfectly okay to reject my opinions. The beauty of open source is that I can simply create a wrapper around what I dislike! :)

I agree. I really winced at that bizarre syntax. I find it strange to read and painfully unintuitive to write. It's not just "un-Pythonic"; it's unlike almost any other library.

I would also imagine the strange structure and all those nested accessors makes debugging and developing for the library itself unnecessarily complicated, thereby impeding contributions to the project itself.

You don't have to do that. It's just the test framework they are using alongside HTTPretty in their examples.

You can just as easily use the traditional unittest.TestCase methods:

  self.assertEqual(HTTPretty.last_request.querystring, "whatever")
  self.assertEqual(HTTPretty.last_request.method, HTTPretty.GET)

That is what I do in my tests.

Ah, I see, thanks!

I wrote a wrapper around httpretty called httpetrified, which uses a python-requests serialization format. Instead of writing multiple lines inside the unit test describing the mocks, you can just record an actual response into a file and refer to it in a decorator.

https://github.com/kanzure/python-requestions#decorator

This seems pretty neat (and you've thought of useful use cases like actually supporting streaming requests, yay!) but anything that involves globally monkey patching the entire socket library always makes me feel a bit like I should just go back and make the rest of my code suck a bit less.

Hmm... now I want this hooked up to a WSGI app in some way. Then you could, for example, have httpbin as a dependency and have it serve httpbin locally, thus giving you effective access to httpbin.org without needing an Internet connection. Or it could make handling some things for testing some web apps easier.

I'm currently building out a python client library for an HTTP rest API so this is invaluable to me. Thank you for the hard work!

Also, does anyone have an open-source project using this I could take a look at? Thanks!

Reply on news.ycombinator.com