Python中的断言用起来非常简单，你可以在assert后面跟上任意判断条件，如果断言失败则会抛出异常。
>>>assert1+1==2
>>>assertisinstance('Hello',str)
>>>assertisinstance('Hello',int)
Traceback(most recent calllast):
File"",line1,in
AssertionError
其实assert看上去不错，然而用起来并不爽。就比如有人告诉你程序错了，但是不告诉哪里错了。很多时候这样的assert还不如不写，写了我就想骂娘。直接抛一个异常来得更痛快一些。
改进方案 #1
一个稍微改进一丢丢的方案就是把必要的信息也放到assert语句后面，比如这样。
>>>s="nothin is impossible."
>>>key="nothing"
>>>assertkeyins,"Key: '{}' is not in Target: '{}'".format(key,s)
Traceback(most recent calllast):
File"",line1,in
AssertionError:Key:'nothing'isnotinTarget:'nothin is impossible.'
看上去还行吧，但是其实写的很蛋疼。假如你是一名测试汪，有成千上万的测试案例需要做断言做验证，相信你面对以上做法，心中一定有千万只那种马奔腾而过。
改进方案 #2
不管你是你是搞测试还是开发的，想必听过不少测试框架。你猜到我要说什么了吧？对，不用测试框架里的断言机制，你是不是洒。
py.test
py.test 是一个轻量级的测试框架，所以它压根就没写自己的断言系统，但是它对Python自带的断言做了强化处理，如果断言失败，那么框架本身会尽可能多地提供断言失败的原因。那么也就意味着，用py.test实现测试，你一行代码都不用改。
import pytest
def test_case():
expected="Hello"
actual="hello"
assertexpected==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语句。
importunittest
classTestStringMethods(unittest.TestCase):
deftest_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轻松完成各种断言语句。
fromptest.decoratorimport*
fromptest.assertionimport*
@TestClass()
classTestCases:
@Test()
deftest1(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 is not equal to str .
"""
改进方案 #3
不仅仅是你和我对Python中的断言表示不满足，所以大家都争相发明自己的assert包。在这里我强烈推荐assertpy 这个包，它异常强大而且好评如潮。
pip install assertpy
看例子:
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')
从它的github 主页 文档上你会发现它支持了几乎你能想到的所有测试场景，包括但不限于以下列表。
Strings
Numbers
Lists
Tuples
Dicts
Sets
Booleans
Dates
Files
Objects
而且它的断言信息简洁明了，不多不少。
Expectedto be oflength<4>,butwas<3>.
Expectedto be empty string,but wasnot.
Expected,but wasnot.
Expectedto contain onlydigits,but didnot.
Expected<123>to contain only alphabeticchars,but didnot.
Expectedto contain only uppercasechars,but didnot.
Expectedto contain only lowercasechars,but didnot.
Expectedto be equalto,but wasnot.
Expectedto benotequalto,butwas.
Expectedto becase-insensitive equalto,but wasnot.
在发现assertpy之前我也想写一个类似的包，尽可能通用一些。但是现在，我为毛要重新去造轮子？完全没必要！
总结
断言在软件系统中有非常重要的作用，写的好可以让你的系统更稳定，也可以让你有更多真正面对对象的时间，而不是在调试代码。
Python中默认的断言语句其实还有一个作用，如果你写了一个类型相关的断言，IDE会把这个对象当成这种类型，这时候智能提示就有如神助。
要不要把内置的断言语句换成可读性更好功能更强大的第三方断言，完全取决于实际情况。比如你真的需要验证某个东西并且很关心验证结果，那么必须不能用简单的assert；如果你只是担心某个点可能有坑或者让IDE认识某个对象，用内置的assert既简单又方便。
所以说，项目经验还是蛮重要的。怎么样才能学好python学好python你需要一个良好的环境，一个优质的开发交流群，群里都是那种相互帮助的人才是可以的，我有建立一个python学习交流群，在群里我们相互帮助，相互关心，相互分享内容，这样出问题帮助你的人就比较多，群号是301，还有056，最后是051，这样就可以找到大神聚合的群，如果你只愿意别人帮助你，不愿意分享或者帮助别人，那就请不要加了，你把你会的告诉别人这是一种分享。
