twistedmatrix.com> writes:
> 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
|--==> On Wed, 12 Jun 2013 23:16:12 -, exar...@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 T
On Jun 12, 2013, at 4:16 PM, exar...@twistedmatrix.com wrote:
[snip]
> So this all means that your application logic can all live on a
> CommandLocator subclass. 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
On 5 Jun, 07:13 pm, f...@64studio.com wrote:
Hi,
following up from ticket #6502, I'm looking for recommendations/best
practices for writing unit-tests for AMP-based code.
As described in the ticket, the issue I'm currently facing is that the
AMP implementation is subtly not re-entrant safe and
Hi,
following up from ticket #6502, I'm looking for recommendations/best
practices for writing unit-tests for AMP-based code.
As described in the ticket, the issue I'm currently facing is that the
AMP implementation is subtly not re-entrant safe and doesn't work with a
synchronous transport, for
