subclassing from unittest

[Charles Smith]

Hi,

I'd like to subclass from unittest.TestCase. I observed something
interesting and wonder if anyone can explain what's going on... some
subclasses create null tests.

I can create this subclass and the test works:

class StdTestCase (unittest.TestCase):
blahblah

and I can create this subsubclass and the test works:

class aaaTestCase (StdTestCase):
moreblahblah

but if I create this subsubclass (or any where the first letter is
capital):

class AaaTestCase (StdTestCase):
differentblahblah

the test completes immediately without any work being done.

I suspect that the answer is in the prefix printed out by the test. I
have diffed both the long output (tests works, on the left) and the
short output (null test, on the right):

test
(TC_02.TestCase_F_0000_ULLA05_xxxxxxxx_AM_Tx) ... <
test suite has <unittest.TestSuite tests=[<unittest.TestSuite
tests=[]>, test suite has <unittest.TestSuite
tests=[<unittest.TestSuite tests=[]>,

> <unittest.TestSuite tests=[]>,
<unittest.TestSuite
tests=[<TC_02.TestCase_F_0000_ULLA05_xxxxxxxx_AM
<unittest.TestSuite tests=[<TC_02.TestCase_F_0000_ULLA05_xxxxxxxx_AM
<unittest.TestSuite
tests=[<TC_02.TestCase_F_0001_ULLA10_xxxxxxxx_AM
<unittest.TestSuite tests=[<TC_02.TestCase_F_0001_ULLA10_xxxxxxxx_AM
<unittest.TestSuite
tests=[<TC_02.TestCase_F_0002_ULLA20_xxxxxxxx_AM
<unittest.TestSuite tests=[<TC_02.TestCase_F_0002_ULLA20_xxxxxxxx_AM
<unittest.TestSuite
tests=[<TC_02.TestCase_F_0003_ULLA05_xxxxxxxx_UM
<unittest.TestSuite tests=[<TC_02.TestCase_F_0003_ULLA05_xxxxxxxx_UM
<unittest.TestSuite
tests=[<TC_02.TestCase_F_0005_ULLA10_xxxxxxxx_UM
<unittest.TestSuite tests=[<TC_02.TestCase_F_0005_ULLA10_xxxxxxxx_UM
<unittest.TestSuite
tests=[<TC_02.TestCase_F_0006_ULLA20_xxxxxxxx_UM |
<unittest.TestSuite tests=[<TC_02.TestCase_F_0006_ULLA20_xxxxxxxx_UM
<unittest.TestSuite
tests=[]>]> <

> ----------> test_api_socket:the address specified is: 127.0.0.1

>

>

>

>
----------------------------------------------------------------------

> Ran 0 tests in 0.000s

>

> OK


I see an empty test somehow gets sorted to the beginning of the list.
How could that be a result of whether the first letter of the class is
capitalized or not?

Thanks in advance...
cts

--------------------------------------------------------
http://www.creative-telcom-solutions.de

[Charles Smith]

Unfortunately, the side-by-side diff didn't come out so well ...

---------------------------------------
http://www.creative-telcom-solutions.de

[Terry Jan Reedy]

On 5/22/2013 11:32 AM, Charles Smith wrote:

Have you red this? I will suggest some specifics.
http://www.catb.org/esr/faqs/smart-questions.html

> I'd like to subclass from unittest.TestCase.

What version of Python.

> I observed something interesting and wonder if anyone can explain
what's going on... some
> subclasses create null tests.
>
> I can create this subclass and the test works:

What does 'works' mean?

> class StdTestCase (unittest.TestCase):
> blahblah

I bet that this (and the rest of your 'code' is not what you actually
ran. Unless blahblah is bound (to what?), this fails with NameError.
Give us what you ran so we can run it too, and modify it.

> and I can create this subsubclass and the test works:
>
> class aaaTestCase (StdTestCase):
> moreblahblah
>
> but if I create this subsubclass (or any where the first letter is
> capital):
>
> class AaaTestCase (StdTestCase):
> differentblahblah
>
> the test completes immediately without any work being done.

What does this mean? I see no difference with the following

import unittest
class StdTestCase (unittest.TestCase): pass
class lowerSub(StdTestCase): pass
class UpperSub(StdTestCase): pass

unittest.main(verbosity=2, exit=False)

# prints (3.3)

----------------------------------------------------------------------
Ran 0 tests in 0.000s

OK

Same as before the subclasses were added.

--
Terry Jan Reedy

[Ulrich Eckhardt]

Am 22.05.2013 17:32, schrieb Charles Smith:
> I'd like to subclass from unittest.TestCase. I observed something
> interesting and wonder if anyone can explain what's going on... some
> subclasses create null tests.

I can perhaps guess what's going on, though Terry is right: Your
question isn't very helpful and informative.

> I can create this subclass and the test works:
>
> class StdTestCase (unittest.TestCase):
> blahblah
>
> and I can create this subsubclass and the test works:
>
> class aaaTestCase (StdTestCase):
> moreblahblah
>
> but if I create this subsubclass (or any where the first letter is
> capital):
>
> class AaaTestCase (StdTestCase):
> differentblahblah
>
> the test completes immediately without any work being done.

Well, per PEP 8, classes use CamelCaps, so your naming might break
automatic test discovery. Then, there might be another thing that could
cause this, and that is that if you have an intermediate class derived
from unittest.TestCase, that class on its own will be considered as test
case! If this is not what you want but you still want common
functionality in a baseclass, create a mixin and then derive from both
the mixin and unittest.TestCase for the actual test cases.

Good luck!

Uli

[Roy Smith]

In article <bar07a-...@satorlaser.homedns.org>,

Ulrich Eckhardt <ulrich....@dominolaser.com> wrote:

> if you have an intermediate class derived
> from unittest.TestCase, that class on its own will be considered as test
> case! If this is not what you want but you still want common
> functionality in a baseclass, create a mixin and then derive from both
> the mixin and unittest.TestCase for the actual test cases.

Or, try another trick I picked up somewhere. When you're done defining
your test classes, delete the intermediate base class, so it won't be
autodiscovered!

class MyBaseTestClass(unittest.TestCase):
pass

class MyRealTest1(MyBaseTestClass):
pass

class MyRealTest2(MyBaseTestCalss):
pass

del MyBaseTestClass

[Terry Jan Reedy]

On 5/23/2013 2:58 AM, Ulrich Eckhardt wrote:

> Well, per PEP 8, classes use CamelCaps, so your naming might break
> automatic test discovery. Then, there might be another thing that could
> cause this, and that is that if you have an intermediate class derived
> from unittest.TestCase, that class on its own will be considered as test
> case! If this is not what you want but you still want common
> functionality in a baseclass, create a mixin and then derive from both
> the mixin and unittest.TestCase for the actual test cases.

This is now standard practice, gradually being implemented everywhere in
the CPython test suite, for testing C and Py versions of a module.

class TestXyz():
mod = None
<test_a, etc, methods>

class TestXyz_C(TestXyz, TextCase): # Test C version
mod = support.import_fresh_module('_xyz') # approximately right

class TestXyz_Py(TestXyz, TextCase): # Test Python version
mod = support.import_fresh('xyz')

This minimizes duplication and ensures that both implementations get
exactly the same tests.

tjr