[Twisted-Python] Testing Strategies (was Re: Streaming Requests)

[Jean-Paul Calderone]

On Wed, Jan 11, 2017 at 11:41 PM, Glyph Lefkowitz <glyph at twistedmatrix.com>
wrote:

>
> On Jan 9, 2017, at 4:13 AM, Jean-Paul Calderone <exarkun at twistedmatrix.com>
> wrote:
>
> On Mon, Jan 9, 2017 at 4:52 AM, Glyph Lefkowitz <glyph at twistedmatrix.com>
> wrote:
>
>> On a related note, 'proto_helpers' is in a super awkward place.
>>  'twisted.testing', anyone? :)
>>
>
> Yes.  I almost suggested this about a week ago when I was preparing to
> contribute some testing code but then realized I couldn't contribute the
> code after all. :(
>
>
> Well, now it's just a matter of time :).
>
>
Some further thoughts on this... What I've actually been doing elsewhere (
*mostly*) is to put the testing implementations quite near the real
implementations.  For example, I recently introduced
`workproject.subscription_manager.{network_client,memory_client}`.  But
contrary to this, in txAWS I'm following the pre-existing pattern which is
more like `txaws.service.AWSServiceRegion.get_ec2_client` &
`txaws.testing.service.FakeAWSServiceRegion.get_ec2_client`.

Which I prefer, I'm not really sure yet.  Role-named modules are easy to
recognize.  On the other hand, testing code next to implementation code is
easier to stumble across and you don't *have* to recognize a separate
testing module to find it.  Also, role-named modules tend to pile up and
get in each other's way (start working with `twisted.testing`,
`txaws.testing`, etc and things start to get confusing quickly).

Additionally, a related idea is that often the testing implementation might
actually serve as a good starting place for the real implementation.  I
think the code in txAWS is a good example of this (ie, the real and fake
implementations duplicate a lot of logic with some pointless divergences).
In the olden days I would have said "the testing implementation is often a
good *base class* for the real implementation".  But now I'll mumble
something about composition.  Put another way:

   - Clock should be the real implementation of all of the time-source
   independent logic of IReactorTime
   - FakeAWSServiceRegion should be the real implementation of the "client
   factory" logic (get_XXX_client) of AWSServiceRegion

and so on.

Perhaps this also speaks to the idea you mentioned that there should be a
stack of thin abstractions but I snipped that content already so I'll try
responding to that separately, later.

Jean-Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20170112/a27e8463/attachment-0002.html>