Python Assert 为何不尽如人意?Python中的断言用起来非常简单，你可以在assert后面跟上任意判断条件，如果断言失败则会抛出异常。
>>> assert 1 + 1 == 2>>> assert isinstance('Hello', str)>>> assert isinstance('Hello', int)Traceback (most recent call last): File "<input>", line 1, in <module>AssertionError
其实assert看上去不错，然而用起来并不爽。就比如有人告诉你程序错了，但是不告诉哪里错了。很多时候这样的assert还不如不写，写了我就想骂娘。直接抛一个异常来得更痛快一些。改进方案 #1一个稍微改进一丢丢的方案就是把必要的信息也放到assert语句后面，比如这样。
>>> s = "nothin is impossible.">>> key = "nothing">>> assert key in s, "Key: '{}' is not in Target: '{}'".format(key, s)Traceback (most recent call last): File "<input>", line 1, in <module>AssertionError: Key: 'nothing' is not in Target: 'nothin is impossible.'
看上去还行吧，但是其实写的很蛋疼。假如你是一名测试汪，有成千上万的测试案例需要做断言做验证，相信你面对以上做法，心中一定有千万只那种马奔腾而过。改进方案 #2不管你是你是搞测试还是开发的，想必听过不少测试框架。你猜到我要说什么了吧？对，不用测试框架里的断言机制，你是不是洒。py.testpy.test 是一个轻量级的测试框架，所以它压根就没写自己的断言系统，但是它对Python自带的断言做了强化处理，如果断言失败，那么框架本身会尽可能多地提供断言失败的原因。那么也就意味着，用py.test实现测试，你一行代码都不用改。
import pytestdef test_case(): expected = "Hello" actual = "hello" assert expected == actualif __name__ == '__main__': pytest.main()"""================================== FAILURES ===================================__________________________________ test_case __________________________________ def test_case(): expected = "Hello" actual = "hello"> assert expected == actualE assert 'Hello' == 'hello'E - HelloE ? ^E + helloE ? ^assertion_in_python.py:7: AssertionError========================== 1 failed in 0.05 seconds ===========================""""
unittestPython自带的unittest单元测试框架就有了自己的断言方法
self.assertXXX()
，而且不推荐使用
assert XXX
语句。
import unittestclass TestStringMethods(unittest.TestCase): def test_upper(self): self.assertEqual('foo'.upper(), 'FoO')if __name__ == '__main__': unittest.main() """FailureExpected :'FOO'Actual :'FoO'Traceback (most recent call last): File "assertion_in_python.py", line 6, in test_upper self.assertEqual('foo'.upper(), 'FoO')AssertionError: 'FOO' != 'FoO'"""
ptest我非常喜欢ptest，感谢Karl大神写了这么一个测试框架。ptest中的断言可读性很好，而且通过IDE的智能提示你能轻松完成各种断言语句。
from ptest.decorator import *from ptest.assertion import *@TestClass()class TestCases: @Test() def test1(self): actual = 'foo' expected = 'bar' assert_that(expected).is_equal_to(actual)"""Start to run following 1 tests:------------------------------...[demo.assertion_in_python.TestCases.test1@Test] Failed with following message:...AssertionError: Unexpectedly that the str <bar> is not equal to str <foo>."""
改进方案 #3不仅仅是你和我对Python中的断言表示不满足，所以大家都争相发明自己的assert包。在这里我强烈推荐assertpy 这个包，它异常强大而且好评如潮。
pip install assertpy
看例子:
from assertpy import assert_thatdef test_something(): assert_that(1 + 2).is_equal_to(3) assert_that('foobar')\ .is_length(6)\ .starts_with('foo')\ .ends_with('bar') assert_that(['a', 'b', 'c'])\ .contains('a')\ .does_not_contain('x')
从它的主页文档上你会发现它支持了几乎你能想到的所有测试场景，包括但不限于以下列表。 Strings Numbers Lists Tuples Dicts Sets Booleans Dates Files Objects而且它的断言信息简洁明了，不多不少。
Expected <foo> to be of length <4>, but was <3>.Expected <foo> to be empty string, but was not.Expected <False>, but was not.Expected <foo> to contain only digits, but did not.Expected <123> to contain only alphabetic chars, but did not.Expected <foo> to contain only uppercase chars, but did not.Expected <FOO> to contain only lowercase chars, but did not.Expected <foo> to be equal to <bar>, but was not.Expected <foo> to be not equal to <foo>, but was.Expected <foo> to be case-insensitive equal to <BAR>, but was not.
在发现assertpy之前我也想写一个类似的包，尽可能通用一些。但是现在，我为毛要重新去造轮子？完全没必要！总结断言在软件系统中有非常重要的作用，写的好可以让你的系统更稳定。Python中默认的断言语句其实还有一个作用，如果你写了一个类型相关的断言，IDE会把这个对象当成这种类型，这时候智能提示就有如神助。要不要把内置的断言语句换成可读性更好功能更强大的第三方断言，完全取决于实际情况。比如你真的需要验证某个东西并且很关心验证结果，那么必须不能用简单的assert；如果你只是担心某个点可能有坑或者让IDE认识某个对象，用内置的assert既简单又方便。所以说，项目经验还是蛮重要的。以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能有所帮助，如果有疑问大家可以留言交流。也站在未路让我牵挂的人。
