TextTestRunner calls str(TestCase) directly, which makes it hard for testscenarios to rename the test cases as it parameterises them (because __str__ is a descriptor). While testscenarios could use a decorator instead, thats undesirable as the test case object would still need to be customised so that calls to self.id() and self.shortDescription() inside it still return consistent information.

So the relevant code is this:
 def getDescription(self, test):
41 if self.descriptions:
42 return test.shortDescription() or str(test)
43 else:
44 return str(test)

What I'd like is to have this be something like:
41 if self.descriptions:
42     return test.shortDescription() or test.id()
43 else:
44     return test.id()

Which would let testscenarios adjust both shortDescriptions and id, and Just Work.

Or anther way this could be done would be to make TestCase.__str__ call self.id(), and then __str__ never needs to be adjusted - id() or shortDescription are the only things to tweak.

By "descriptor" I think you really mean it is a special method (ie: looked up on the class only, not on an instance).  A descriptor is something else.

This is a feature request and could only be implemented in 3.4.  Assuming I'm understanding what you are asking for (which is not certain), as a partial workaround you could reset _testMethodName.

They aren't descriptors? They certainly aren't normal methods:
>>> class foo(object):
...   def __str__(self): return "foo"
... 
>>> f = foo()
>>> f.__str__ = lambda: "bar"
>>> str(f)
'foo'

I *thought* the mechanism by which they can only be replaced by altering the class *was* descriptors, but I gladly seek better info!

_testMethodName is overloaded though: its both 'what is the test method' and 'part of the description or id of the test', so resetting it would be - at best - risky when only changing the description or id.

The special handling of special methods is baked into the attribute lookup machinery.  The discussion of this is in the language reference somewhere, as is the explanation of what descriptors are and how they work.

> So the relevant code is this:
> def getDescription(self, test):
> ...
> 43 return str(test)
> ...
> What I'd like is to have this be something like:
> 44     return test.id()

> Or anther way this could be done would be to make TestCase.__str__ call self.id()

Note that str(test) and test.id() don't return the same value.  The former is the "friendly" name.  It is probably intentional that TextTestResult uses the TestCase instance's friendly name in its getDescription() method as opposed to the id.

> TextTestRunner calls str(TestCase) directly, which makes it hard for testscenarios to rename the test cases as it parameterises them

What about testscenarios subclassing the TestCase instances as it parametrizes them?

    class ScenariosTestCase(case.__class__):
        def __str__(self):
            return "testscenarios test name..."
    case.__class__ = ScenariosTestCase
    print(str(case))

From the documentation, it looks like testscenarios creates new test objects from the originals anyways.  Alternatively (although I don't if testscenarios can control what test runner is being used), TextTestRunner could be subclassed with its own getDescription() method.

http://docs.python.org/reference/datamodel.html#special-method-lookup-for-new-style-classes

testscenarios copies the tests, it doesn't call the constructor for the class; this makes things a lot simpler than trying to reconstruct whatever state the object may have from scratch again.

As for str(test) and test.id() being different - well sure they are today, but I don't know that the str(test) format is /useful/ today, as its not a particularly good str() anyhow. It doesn't identify that its a test instance even. 

This suggests two alternatives to me:
 - decide that we want three things: id, friendly-id and shortDescription, and have three non-magic methods, which TextTestRunner can call depending on what the user wants to see.
 - decide we want two things, id and shortDescription, and TextTestRunner can combine these things to meet the users request. (e.g. id + ' ' + shortDescription)

And separately, as the __str__ isn't particularly good anyhow, perhaps we should take the opportunity to think about what we want from it and adjust it.

So three including str sounds sufficient to me: short description, long description and repr (with str == repr) for debugging.

Robert: I don't know if there's something funky going on with your browser, but every time you post the 'enhancement' setting for type seems to get lost.

@Michael I'll put a patch together next week then.
@R.david.murray no idea - but I've refreshed the page, we'll if it behaves better. My guess would be a buggy in-flight-collision detection in the issue tracker code.

> testscenarios copies the tests, it doesn't call the constructor for the class;

My suggestion on how to override __str__ (by assignment to __class__) doesn't require that the constructor be called.

Much more likely that you just needed to refresh the page, going by my own experience with this kind of problem (especially seeing as that seems to have fixed it :)

@Chris - I don't like the idea of making new classes on the fly like that, it seems more likely to provoke bugs (as type(case) != SomeSpecificClass) anymore after that, vs just not relying on __str__ directly.

Going back to Michael's proposal of short description, long description and repr (with str == repr) for debugging. - that is missing id(), and id() is IMO definitely still needed.

I was proposing id(), friendlyId(), shortDescription(), and __str__ calls friendlyId(), and __repr__ is a regular <...> repr.

An idea occurred to me on this recently. Instead of changing TextTestResult to call test.id() everywhere instead of str(test), what about making TextTestResult DRY by having it call a new method called something like self.getName(test)?

With this approach, customizing the test name would simply be a matter of subclassing TextTestResult and overriding TextTestResult.getName() (which unittest makes easy). This is much easier than trying to modify the test cases themselves (which unittest doesn't make easy). It's also more natural as the responsibility for formatting should lie with the test result classes rather than with the test case classes themselves (e.g. as discussed in #22431).