我正在Django做一些单元测试。 TestCase类与此类中的实际方法之间有什么关系?组织这些东西的最佳做法是什么?
例如,我有
class Test(TestCase):
def __init__(self):
...
def testTestA(self):
#test code
def testTestB(self):
#test code
如果我以这种方式组织:
class Test1(TestCase):
def __init__(self):
...
def testTestA(self):
#test code
class Test2(TestCase):
def __init__(self):
...
def testTestB(self):
...
哪个更好,有什么区别?
谢谢!
答案 0 :(得分:8)
您很少为__init__
撰写TestCase
。所以从你的单元测试心理模型中得出结论。
您有时会写一个setUp
和tearDown
。但是,Django会自动执行大部分操作,您通常只提供一个用于填充测试数据库的静态fixtures=
变量。
更基本的是,什么是测试用例?
测试用例是一个“夹具” - 一个被测单元的配置 - 然后你可以运用。理想情况下,每个TestCase都有一个setUp
方法,可以创建一个夹具。每个方法都会对该夹具执行操作,并声明操作有效。
然而。这没什么教条。
在许多情况下 - 特别是在锻炼Django模型时 - 那里没有那么多有趣的操作。
如果你没有覆盖模型中的save
,你根本不需要进行CRUD测试。您可以(并且应该)信任ORM。 [如果你不相信它,那么得到你做信任的新框架。]
如果模型类中有一些属性,则可能不希望创建一个不同的方法来测试每个属性。您可能只想在单个TestCase的单个方法中按顺序测试它们。
如果,OTOH,你真的有很多状态变化的复杂类,你需要一个独特的TestCase来配置一个对象是一个状态,将它操纵到另一个状态并断言所有变化都表现正确。
查看函数,因为它们在技术上不是有状态的,完全不符合单元测试理念。在执行setUp
创建处于已知状态的单元时,您正在使用客户端界面逐步执行某些交互以创建处于已知状态的会话。一旦会话达到所需状态,那么您的各种测试方法将执行该会话,并断言事情有效。
<强>摘要强>
将TestCase视为将在其中运行测试的“设置”或“上下文”。
将每个方法都视为“when_X_should_Y”语句。有些人建议使用这种名称(“test_when_x_should_y”),因此该方法将执行“X”并断言“Y”是响应。
答案 1 :(得分:1)
关于案例A和B的正确组织以及测试方法1,2和3,这个问题很难回答......
然而,将测试拆分为测试用例有两个主要目的: 1)围绕一些逻辑组组织测试,例如CustomerViewTests,OrdersAggregationTests等。
2)共享相同的setUp()和tearDown()方法,用于需要相同,良好,设置和拆除的测试。
更多信息和示例可以在unitTest documentation找到。