Python中断言Assertion的一些改进方案
PythonAssert为何不尽如人意?
Python中的断言用起来非常简单,你可以在assert后面跟上任意判断条件,如果断言失败则会抛出异常。
>>>assert1+1==2 >>>assertisinstance('Hello',str) >>>assertisinstance('Hello',int) Traceback(mostrecentcalllast): File"<input>",line1,in<module> AssertionError
其实assert看上去不错,然而用起来并不爽。就比如有人告诉你程序错了,但是不告诉哪里错了。很多时候这样的assert还不如不写,写了我就想骂娘。直接抛一个异常来得更痛快一些。
改进方案#1
一个稍微改进一丢丢的方案就是把必要的信息也放到assert语句后面,比如这样。
>>>s="nothinisimpossible." >>>key="nothing" >>>assertkeyins,"Key:'{}'isnotinTarget:'{}'".format(key,s) Traceback(mostrecentcalllast): File"<input>",line1,in<module> AssertionError:Key:'nothing'isnotinTarget:'nothinisimpossible.'
看上去还行吧,但是其实写的很蛋疼。假如你是一名测试汪,有成千上万的测试案例需要做断言做验证,相信你面对以上做法,心中一定有千万只那种马奔腾而过。
改进方案#2
不管你是你是搞测试还是开发的,想必听过不少测试框架。你猜到我要说什么了吧?对,不用测试框架里的断言机制,你是不是洒。
py.test
py.test是一个轻量级的测试框架,所以它压根就没写自己的断言系统,但是它对Python自带的断言做了强化处理,如果断言失败,那么框架本身会尽可能多地提供断言失败的原因。那么也就意味着,用py.test实现测试,你一行代码都不用改。
importpytest deftest_case(): expected="Hello" actual="hello" assertexpected==actual if__name__=='__main__': pytest.main() """ ==================================FAILURES=================================== __________________________________test_case__________________________________ deftest_case(): expected="Hello" actual="hello" >assertexpected==actual Eassert'Hello'=='hello' E-Hello E?^ E+hello E?^ assertion_in_python.py:7:AssertionError ==========================1failedin0.05seconds=========================== """"
unittest
Python自带的unittest单元测试框架就有了自己的断言方法self.assertXXX(),而且不推荐使用assertXXX语句。
importunittest classTestStringMethods(unittest.TestCase): deftest_upper(self): self.assertEqual('foo'.upper(),'FoO') if__name__=='__main__': unittest.main() """ Failure Expected:'FOO' Actual:'FoO' Traceback(mostrecentcalllast): File"assertion_in_python.py",line6,intest_upper self.assertEqual('foo'.upper(),'FoO') AssertionError:'FOO'!='FoO' """
ptest
我非常喜欢ptest,感谢Karl大神写了这么一个测试框架。ptest中的断言可读性很好,而且通过IDE的智能提示你能轻松完成各种断言语句。
fromptest.decoratorimport* fromptest.assertionimport* @TestClass() classTestCases: @Test() deftest1(self): actual='foo' expected='bar' assert_that(expected).is_equal_to(actual) """ Starttorunfollowing1tests: ------------------------------ ... [demo.assertion_in_python.TestCases.test1@Test]Failedwithfollowingmessage: ... AssertionError:Unexpectedlythatthestr<bar>isnotequaltostr<foo>. """
改进方案#3
不仅仅是你和我对Python中的断言表示不满足,所以大家都争相发明自己的assert包。在这里我强烈推荐assertpy这个包,它异常强大而且好评如潮。
pipinstallassertpy
看例子:
fromassertpyimportassert_that deftest_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>tobeoflength<4>,butwas<3>. Expected<foo>tobeemptystring,butwasnot. Expected<False>,butwasnot. Expected<foo>tocontainonlydigits,butdidnot. Expected<123>tocontainonlyalphabeticchars,butdidnot. Expected<foo>tocontainonlyuppercasechars,butdidnot. Expected<FOO>tocontainonlylowercasechars,butdidnot. Expected<foo>tobeequalto<bar>,butwasnot. Expected<foo>tobenotequalto<foo>,butwas. Expected<foo>tobecase-insensitiveequalto<BAR>,butwasnot.
在发现assertpy之前我也想写一个类似的包,尽可能通用一些。但是现在,我为毛要重新去造轮子?完全没必要!
总结
断言在软件系统中有非常重要的作用,写的好可以让你的系统更稳定。Python中默认的断言语句其实还有一个作用,如果你写了一个类型相关的断言,IDE会把这个对象当成这种类型,这时候智能提示就有如神助。
要不要把内置的断言语句换成可读性更好功能更强大的第三方断言,完全取决于实际情况。比如你真的需要验证某个东西并且很关心验证结果,那么必须不能用简单的assert;如果你只是担心某个点可能有坑或者让IDE认识某个对象,用内置的assert既简单又方便。
所以说,项目经验还是蛮重要的。以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能有所帮助,如果有疑问大家可以留言交流。