大多数测试框架都假设“ 1个测试= 1个Python方法/函数”,
并考虑在函数执行时不通过测试
提出断言.
我正在测试类似编译器的程序(读取* .foo的程序
文件并处理其内容),为此,我想对许多输入(* .foo)文件执行相同的测试. IOW,我的测试看起来像:
class Test(unittest.TestCase):
def one_file(self, filename):
# do the actual test
def list_testcases(self):
# essentially os.listdir('tests/') and filter *.foo files.
def test_all(self):
for f in self.list_testcases():
one_file(f)
我当前的代码使用
来自unittest
Python的标准库,即one_file使用self.assert …(…)
语句以检查测试是否通过.
在我确实获得成功/失败的程序的意义上,这有效
当我的代码正常/笨拙时,但我失去了很多优势
测试框架:
>我没有得到“ Y测试中的X失败”之类的相关报告,也没有
通过/失败测试的列表. (我打算使用这样的系统
不仅要测试我自己的发展,还要对学生的代码进行评分
作为老师,所以报告对我很重要)
>我没有测试独立性.第二项测试在
首先离开的环境,依此类推.第一次失败停止
测试人员:失败后出现的测试用例根本不运行.
>我感觉到我正在滥用测试框架:只有
一项测试功能,因此可以自动测试单元测试声音
例如过度杀伤力.可以(应该?)编写相同的代码
具有基本断言的纯Python.
一个明显的替代方法是将我的代码更改为
class Test(unittest.TestCase):
def one_file(self, filename):
# do the actual test
def test_file1(self):
one_file("first-testcase.foo")
def test_file2(self):
one_file("second-testcase.foo")
然后,我获得了单元测试的所有优点,但是:
>需要编写更多代码.
>很容易“忘记”一个测试用例,即在其中创建一个测试文件
tests /,忘记将其添加到Python测试中.
我可以想象一个解决方案,其中我将为每个测试用例动态生成一个方法(沿着setattr(self,’test_file’str(n),…)行),从而为第二个解决方案生成代码,而无需编写它用手.但这听起来似乎并不复杂,但用例似乎并不复杂.
我如何才能充分发挥两者的优势
自动测试用例发现(列出测试/*.foo文件),测试
独立性和适当的报告?