[Twisted-Python] Testing AMP-based code

[Free Ekanayaka]

|--==> On Wed, 12 Jun 2013 23:16:12 -0000, exarkun at twistedmatrix.com said:

  > I think this is thinking in the right direction.  Twisted generally
  > tries to be responsible for testing its own code, and the
  > serialization from commands to bytes (and the reverse) that AMP does
  > is part of Twisted, so you should really be free from the burden of
  > testing that that stuff works.

Agreed. Thanks for the detailed explanation about the AMP internals, I
hadn't take time yet to fully read the implementation, I did now and
your directions helped.

I'm certainly happy to integrate the docs with this information as Glyph
suggested.

  > So this all means that your application logic can all live on a
  > CommandLocator subclass.

Indeed, I had figured out this particular bit already.

  > When you really want to put this on an AMP server, you can hook an
  > AMP instance up to your CommandLocator subclass (AMP takes a locator
  > as an __init__ argument).  When you want to test your command
  > implementations, you can hook the CommandLocator up to a
  > BoxDispatcher and a box sender and throw boxes straight at it with
  > no network interation.

Okay this is where it get interesting and I'd like to hear for opinions
for a few different possibilities. Following the your idea above, I've
put together this little example of application code with tests (it
expands the one attached to the ticket):

http://pastebin.com/6hTw5WDC

I've included some comments that are not really code comments, but
rather just express issues/considerations.

I believe there are two parts of application code that you want to test
(possibly differently). One part are the application-defined AMP
commands and their responders, the other part is the application client
code that make use of them via callRemote. So basically two different
layers.

My question is probably if folks have any opinion about whether to mock
the parts of your applications that invoke callRemote (typically by
providing fakes, so you don't invoke callRemote at all), or
alternatively to fake callRemote itself. As I wrote in the paste, this
probably drifts towards a "state-based vs behavior-based" matter.

  > Some pieces are probably still missing from the public API - for
  > example, you do want to test that your objects all get properly
  > serialized and deserialized through AMP, particularly if you're
  > implementing custom Argument types.  There are some private APIs,
  > _objectsToStrings and _stringsToObjects mostly, that really help with
  > testing this, and we should think about how to expose this
  > functionality publically.  Also, we should document this whole pile of
  > stuff.

I do have custom Argument types. Those could be exercised indirectly by
faking callRemote the way the FakeBoxDispatcher class in the paste does,
but there might be nicer approaches.

  > Maybe you'd be interested in writing something up after you've
  > had a chance to play with these ideas?

Sure. It feels part of these questions are not purely AMP-specific and
are generally relevant for testing application code that uses protocols
indirectly. I guess a popular approach is to wrap protocols inside
"Client" classes and then provide fake versions of those clients, which
at the end is perhaps what I should do in this case too (e.g. fake the
MathClient in the code).

Cheers,

Free