gpt4 book ai didi

Python中断言Assertion的一些改进方案

转载 作者:qq735679552 更新时间:2022-09-27 22:32:09 24 4
gpt4 key购买 nike

CFSDN坚持开源创造价值,我们致力于搭建一个资源共享平台,让每一个IT人在这里找到属于你的精彩世界.

这篇CFSDN的博客文章Python中断言Assertion的一些改进方案由作者收集整理,如果你对这篇文章有兴趣,记得点赞哟.

Python Assert 为何不尽如人意?

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

?
1
2
3
4
5
6
7
>>> 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语句后面,比如这样.

?
1
2
3
4
5
6
7
>>> 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.test 。

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

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
import pytest
 
def test_case():
   expected = "Hello"
   actual = "hello"
   assert expected = = actual
 
if __name__ = = '__main__' :
   pytest.main()
 
"""
================================== FAILURES ===================================
__________________________________ test_case __________________________________
 
   def test_case():
     expected = "Hello"
     actual = "hello"
>    assert expected == actual
E    assert 'Hello' == 'hello'
E     - Hello
E     ? ^
E     + hello
E     ? ^
 
assertion_in_python.py:7: AssertionError
========================== 1 failed in 0.05 seconds ===========================
""" "

unittest 。

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

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
import unittest
 
class TestStringMethods(unittest.TestCase):
 
   def test_upper( self ):
     self .assertEqual( 'foo' .upper(), 'FoO' )
 
if __name__ = = '__main__' :
   unittest.main()
  
"""
Failure
Expected :'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的智能提示你能轻松完成各种断言语句.

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
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 这个包,它异常强大而且好评如潮.

?
1
pip install assertpy

看例子

?
1
2
3
4
5
6
7
8
9
10
11
from assertpy import assert_that
 
def 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 。

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

?
1
2
3
4
5
6
7
8
9
10
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既简单又方便.

所以说,项目经验还是蛮重要的。以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能有所帮助,如果有疑问大家可以留言交流.

最后此篇关于Python中断言Assertion的一些改进方案的文章就讲到这里了,如果你想了解更多关于Python中断言Assertion的一些改进方案的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com