Python Assert

本文探讨了Python中默认断言的不足及其改进方案,包括自定义断言信息、使用测试框架如py.test和unittest,以及推荐了assertpy库。断言的改进能提高代码的可读性和调试效率,选择合适的断言方式取决于具体需求。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Python中的断言用起来非常简单,你可以在assert后面跟上任意判断条件,如果断言失败则会抛出异常。

  1. >>> assert 1 + 1 == 2

  2. >>> assert isinstance('Hello', str)

  3. >>> assert isinstance('Hello', int)

  4.  
  5. Traceback (most recent call last):

  6. File "<input>", line 1, in <module>

  7. AssertionError

其实assert看上去不错,然而用起来并不爽。就比如有人告诉你程序错了,但是不告诉哪里错了。很多时候这样的assert还不如不写,写了我就想骂娘。直接抛一个异常来得更痛快一些。

改进方案 #1

一个稍微改进一丢丢的方案就是把必要的信息也放到assert语句后面,比如这样。

 
  1. >>> s = "nothin is impossible."

  2. >>> key = "nothing"

  3. >>> assert key in s, "Key: '{}' is not in Target: '{}'".format(key, s)

  4.  
  5. Traceback (most recent call last):

  6. File "<input>", line 1, in <module>

  7. AssertionError: Key: 'nothing' is not in Target: 'nothin is impossible.'

看上去还行吧,但是其实写的很蛋疼。假如你是一名测试汪,有成千上万的测试案例需要做断言做验证,相信你面对以上做法,心中一定有千万只那种马奔腾而过。

改进方案 #2

不管你是你是搞测试还是开发的,想必听过不少测试框架。你猜到我要说什么了吧?对,不用测试框架里的断言机制,你是不是洒。

py.test

py.test 是一个轻量级的测试框架,所以它压根就没写自己的断言系统,但是它对Python自带的断言做了强化处理,如果断言失败,那么框架本身会尽可能多地提供断言失败的原因。那么也就意味着,用py.test实现测试,你一行代码都不用改。

 
  1. import pytest

  2.  
  3. def test_case():

  4. expected = "Hello"

  5. actual = "hello"

  6. assert expected == actual

  7.  
  8. if __name__ == '__main__':

  9. pytest.main()

  10.  
  11. """

  12. ================================== FAILURES ===================================

  13. __________________________________ test_case __________________________________

  14.  
  15. def test_case():

  16. expected = "Hello"

  17. actual = "hello"

  18. > assert expected == actual

  19. E assert 'Hello' == 'hello'

  20. E - Hello

  21. E ? ^

  22. E + hello

  23. E ? ^

  24.  
  25. assertion_in_python.py:7: AssertionError

  26. ========================== 1 failed in 0.05 seconds ===========================

  27. """"

unittest

Python自带的unittest单元测试框架就有了自己的断言方法self.assertXXX(),而且不推荐使用assert XXX语句。

 
  1. import unittest

  2.  
  3. class TestStringMethods(unittest.TestCase):

  4.  
  5. def test_upper(self):

  6. self.assertEqual('foo'.upper(), 'FoO')

  7.  
  8. if __name__ == '__main__':

  9. unittest.main()

  10.  
  11. """

  12. Failure

  13. Expected :'FOO'

  14. Actual :'FoO'

  15.  
  16. Traceback (most recent call last):

  17. File "assertion_in_python.py", line 6, in test_upper

  18. self.assertEqual('foo'.upper(), 'FoO')

  19. AssertionError: 'FOO' != 'FoO'

  20. """

ptest

我非常喜欢ptest,感谢Karl大神写了这么一个测试框架。ptest中的断言可读性很好,而且通过IDE的智能提示你能轻松完成各种断言语句。

 
  1. from ptest.decorator import *

  2. from ptest.assertion import *

  3.  
  4. @TestClass()

  5. class TestCases:

  6. @Test()

  7. def test1(self):

  8. actual = 'foo'

  9. expected = 'bar'

  10. assert_that(expected).is_equal_to(actual)

  11.  
  12. """

  13. Start to run following 1 tests:

  14. ------------------------------

  15. ...

  16. [demo.assertion_in_python.TestCases.test1@Test] Failed with following message:

  17. ...

  18. AssertionError: Unexpectedly that the str <bar> is not equal to str <foo>.

  19. """

改进方案 #3

不仅仅是你和我对Python中的断言表示不满足,所以大家都争相发明自己的assert包。在这里我强烈推荐assertpy 这个包,它异常强大而且好评如潮。

pip install assertpy

看例子:

 
  1. from assertpy import assert_that

  2.  
  3. def test_something():

  4. assert_that(1 + 2).is_equal_to(3)

  5. assert_that('foobar')\

  6. .is_length(6)\

  7. .starts_with('foo')\

  8. .ends_with('bar')

  9. assert_that(['a', 'b', 'c'])\

  10. .contains('a')\

  11. .does_not_contain('x')

从它的github 主页 文档上你会发现它支持了几乎你能想到的所有测试场景,包括但不限于以下列表。

  • Strings
  • Numbers
  • Lists
  • Tuples
  • Dicts
  • Sets
  • Booleans
  • Dates
  • Files
  • Objects

而且它的断言信息简洁明了,不多不少。

 
  1. Expected <foo> to be of length <4>, but was <3>.

  2. Expected <foo> to be empty string, but was not.

  3. Expected <False>, but was not.

  4. Expected <foo> to contain only digits, but did not.

  5. Expected <123> to contain only alphabetic chars, but did not.

  6. Expected <foo> to contain only uppercase chars, but did not.

  7. Expected <FOO> to contain only lowercase chars, but did not.

  8. Expected <foo> to be equal to <bar>, but was not.

  9. Expected <foo> to be not equal to <foo>, but was.

  10. Expected <foo> to be case-insensitive equal to <BAR>, but was not.

在发现assertpy之前我也想写一个类似的包,尽可能通用一些。但是现在,我为毛要重新去造轮子?完全没必要!

总结

断言在软件系统中有非常重要的作用,写的好可以让你的系统更稳定,也可以让你有更多面对(女)对象的时间,而不是在调试代码。

Python中默认的断言语句其实还有一个作用,如果你写了一个类型相关的断言,IDE会把这个对象当成这种类型,这时候智能提示就有如神助。

要不要把内置的断言语句换成可读性更好功能更强大的第三方断言,完全取决于实际情况。比如你真的需要验证某个东西并且很关心验证结果,那么必须不能用简单的assert;如果你只是担心某个点可能有坑或者让IDE认识某个对象,用内置的assert既简单又方便。

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值