Opened 8 years ago

Closed 8 years ago

#3604 enhancement closed duplicate (duplicate)

Create a single definitive module for commonly used test helpers and consolidate usage from existing test modules

Reported by: Jean-Paul Calderone Owned by:
Priority: high Milestone:
Component: core Keywords:
Cc: Branch:


There is crazy sprawl in our test suite of "utilities":

  • twisted/test/ - some random garbage, probably mostly PB related, but not really documented well enough that one could use it
  • twisted/test/ - some context factories; why would anyone even need these? we have context factories already.
  • twisted/test/ - essentially just a deprecated module with an old implementation of Clock
  • twisted/test/ - probably the most widely used helper module; the stuff it contains could be seriously better than it is, though

There's probably lots of duplication in individual test_*.py files as well. This makes maintenance harder. It makes writing new tests harder, since it's hard to find existing utilities and often we end up just re-writing them from scratch, usually with bugs. There should be exactly one module in Twisted for this kind of code and all of our test utilities should be in it.

Change History (4)

comment:1 Changed 8 years ago by Glyph

I am not quite sure that this ticket is the appropriate venue to express this sentiment, since it's not necessarily the same work, but it's related. However, it's gone too long without being written down somewhere.

We should start having a firm division between temporary fakes or throwaway test facilities, which are themselves part of the tests and therefore not tested, and test-friendly but robust implementation artifacts, which are tested, and maintained in their own right. I can't find a test-patterns vocabulary to describe these two categories of thing, so I propose we restrict our usage of the phrase "test helpers" to things that actually have their own tests.

Perhaps the most important distinction between "helpers" and "fakes" is that nobody should be importing fakes but we should encourage users of Twisted to import and use helpers rather than implementing their own fakes. To wit, I don't think that helpers should be located in the "test" package, since part of our (unfortunately implicit) understanding about compatibility is that nobody should import anything from the "test" package.

comment:2 Changed 8 years ago by Glyph

Also, it's worth noting that we should avoid "test" terminology when implementing these helpers. In many cases the "fake" implementation is useful in its own right; for example, sqlite supports in-memory databases, and the "in-memory" property of those databases is a lot more interesting than the "test" property. When we do an in-memory ITransport or IFilePath or whatever, it should be suitable for non-test applications.

comment:3 Changed 8 years ago by Jean-Paul Calderone

Resolution: duplicate
Status: newclosed

This is a duplicate of #1945.

comment:4 Changed 6 years ago by <automation>

Owner: Glyph deleted
Note: See TracTickets for help on using tickets.