2013-02-18 69 views
6

我将Python项目的测试套件从unittest转换为鼻子。该项目的现有框架(基于unittest)相当笨拙,包含大量定制的测试代码以用于测试发现和运行,所以我试图迁移到鼻子以使所有事情都变得更加流畅。Python鼻子测试继承:从子类加载单元测试装置

但是,我正在生成测试套件的代码面临问题。

该项目的框架有两种运行测试的方式。一个是

class TestSomething(unittest.TestCase): 

    def setUp(self): 
     ... 

    def test_x(self): 
     ... 

    def test_y(self): 
     ... 

suite = unittest.TestSuite() 
suite.addTest(unittest.makeSuite(TestSomething)) 

这是“直接”的方式,这是所有鼻子的例子和教程显示,它的工作原理。然而,第二种方式是通过定义一个包含所有的测试逻辑测试类,然后在含有不同的安装配置和继承父类的测试不同子类中创建测试用例:

class TestSomething(unittest.TestCase): 

    def test_x(self): 
     ... 

    def test_y(self): 
     ... 

class TestCase1(TestSomething): 

    def setUp(self): 
     ... 

class TestCase2(TestSomething): 

    def setUp(self): 
     ... 

suite = unittest.TestSuite() 

cases = [TestCase1,TestCase2] 
suite.addTests([unittest.makeSuite(case) for case in cases]) 

这是鼻子失败用。它试图首先运行测试方法,这显然不起作用,因为超类中没有setUp(),并且test_x()和test_y()中使用的许多变量尚未定义。

我还没有在任何地方发现任何这样做的例子,鼻子(相当稀疏和难以导航)文档似乎也没有提到它。这怎么能与鼻子一起工作?任何帮助将不胜感激。

回答

13

首先,正如unutbu指出的那样,您不应该给TestSomething一个以Test开头的名称,因为nose会自动将这些类视为测试用例。此外,nose运行所有TestCase子,他发现,这样做:

class Something(unittest.TestCase): 
    ... 

给出确切你有相同的结果。我想你不应该从TestCase继承和使用该类作为一个mix-in:

class Something(object): 
    def test_x(self): 
     # here the various assertEqual etc. do not resolve, but you can use them 
     # as if they were present, since in real test-cases they will be inherited 
     # from unittest.TestCase. 
     ... 
    ... 

class TestCase1(unittest.TestCase, Something): 
    def setUp(self): 
     ... 

的其他方式做到这一点是设置类的__test__属性False

class TestSomething(unittest.TestCase): 
    __test__ = False 
    def test_x(self): 
     ... 


class TestCase1(TestSomething): 
    __test__ = True #must put this 
    def setUp(self): 
     ... 

另外,您可以使用nose.istestnose.nottest,以纪念这班是一个测试用例,哪一个不是:

@tools.nottest 
class TestSomething(unittest.TestCase): 
    def test_x(self): 
     ... 

@tools.istest 
class TestCase1(TestSomething): 
    sef setUp(self): 
     ... 
+0

用鼻子装饰s做了诡计;回头看,现在看起来非常明显,但有时最明显的解决方案是最难以捉摸的解决方案......非常感谢提示! – Boris 2013-02-18 12:31:46