看一下Python unittest
文档,同时回顾一下我曾经在这里进行的一系列Django单元测试,这些都是我的发现。
第一件事是最简单的事情,而我认为两者之间最大的不同是可以使用每个命令的情况。在测试类的情况下,它们都可以互换使用,但是,要使用该assertIn
命令,您需要导入unittest库。所以,说我想知道是否h
在hello
。通过assertIn
命令执行此操作的简单方法是:
class MyTestCase(unittest.TestCase):
def is_h_in_hello(self):
self.assertIn("h", "hello")
然后我需要运行测试,即通过unittest.main()
本示例进行测试,以获得答案。但是,使用该assert
命令可以更轻松地查看h
inhello
。这样做非常简单:
assert "h" in "hello"
但本质上,两者都会给我相同的答案。但是,两种方法的区别在于第二种方法的使用简便。
我发现的第二个区别是结果在Python Shell上的可读性。该unittest
库的设计,使得命令是非常具体的。因此,如果测试失败,您将收到一条非常明确的消息,指出出了什么问题。现在说,你想看看是否b
在hello
。通过class方法(只需更改"h"
为"b"
)进行操作,运行测试后得到的消息是:
AssertionError: 'b' not found in 'hello'
----------------------------------------------------------------------
Ran 1 test in 0.038s
Failed (failures=1)
因此,它非常清楚地告诉您:'b' not found in 'hello'
,这使您很方便地查看问题所在。但是说您通过assert
命令执行相同的过程。生成的错误消息类似于:
Traceback (most recent call last):
File "<pyshell#2>", line 1, in <module>
assert "b" in "hello"
AssertionError
尽管它告诉您错误类型(AssertionError
)和回溯,但并没有特别告诉您"b" is NOT in "hello"
。在这种简单的情况下,很容易查看回溯并说哦,您好!但是,在更复杂的情况下,要弄清为什么会生成此错误消息可能会很棘手。
总体而言,这两种方法非常相似,可以为您提供所需的结果,但是从本质上讲,这归因于此处和此处的微小差异,更少的代码行以及Shell消息的直接性。