On 12/30/05, Paul Swartz wrote:

I'm not sure if Conch is the only project that did this, but it used the trial.unittest.* functions instead of methods on TestCases. I used them to avoid having to pass TestCase instances around all over the places, or using a global variable. To avoid the depreciation warnings, I've starting using the unittest._inst global variable, but I doubt that this is the appropriate way to change my code. Is this just not a supported way of using Trial, or is there something else I should be doing?

This is just not a supported way of using Trial. jml

On 1/1/06, James Y Knight wrote:

On Dec 31, 2005, at 5:16 AM, Jonathan Lange wrote:

...

On 12/30/05, Paul Swartz wrote:

...

I'm not sure if Conch is the only project that did this, but it used the trial.unittest.* functions instead of methods on TestCases. I used them to avoid having to pass TestCase instances around all over the places, or using a global variable. To avoid the depreciation warnings, I've starting using the unittest._inst global variable, but I doubt that this is the appropriate way to change my code. Is this just not a supported way of using Trial, or is there something else I should be doing?

This is just not a supported way of using Trial.

Given that the methods don't use self at all (and at least I can't forsee any need to in the future), is there a reason they can't be class methods, so that unittest.TestCase.assertEquals(a, b) would work?

I'm not sure that there is a good reason for doing so. From what I can gather, the assertions in the conch tests are part of extensions to conch's application code. I think that this a Bad Thing. If Trial's assertions remain instance methods only, then the natural way of using Trial will be to put assertions in the actual test_ methods. I think that this is a Good Thing[1]. cheers, jml [1]. I think that to do otherwise is to dilute the meaning of the phrase 'unit test'.