On Sep 21, 2014, at 10:36 AM, Glyph
If anything I'd say that the problem with this code is that it's not a public, documented interface. The clients of this library might want to test it as well :).
Ah! You are referring to both _wrap and _issueRequest here, right? That makes sense, and it’s easy to make those documented public interfaces.
If you're going to check the bytes in a StringTransport, that means you need an implementation of the other end of the protocol as well. If you're just asserting about the exact bytes, then that's really brittle and will break in response to lots of incidental changes.
You can use this as a part of a higher-level testing strategy, like so:
https://github.com/rackerlabs/mimic/blob/master/mimic/test/helpers.py
but in this case the unit test code doesn't see the response to its requests until it's been parsed into a sensible data structure, and assertions are about that.
Okay, this makes sense. Of course, Twisted doesn’t come with an implementation of a memcache server, and I’d rather not implement one myself for the purpose of testing. I think I’ll stick with my latest approach, then. Would you employ the same approach for testing non-wrappers as well? That is, if you were testing the client implementation of some wire protocol, would you still write parsers for the server implementation of the protocol to make assertions about the sent bytes? As far as I can tell, this is not what, say, the existing memcache protocol tests do.