這篇文章主要介紹了python錯(cuò)誤調(diào)試及單元文檔測(cè)試過(guò)程解析,文中通過(guò)示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友可以參考下

錯(cuò)誤分為程序的錯(cuò)誤和由用戶錯(cuò)誤的輸入引起的錯(cuò)誤，此外還有因?yàn)楦鞣N各樣意外的情況導(dǎo)致的錯(cuò)誤，比如在磁盤滿的時(shí)候?qū)懭?、從網(wǎng)絡(luò)爬取東西的時(shí)候，網(wǎng)絡(luò)斷了。這類錯(cuò)誤稱為異常

錯(cuò)誤處理

普通的錯(cuò)誤處理機(jī)制就是在出錯(cuò)的時(shí)候返回一個(gè)錯(cuò)誤代碼，但是這樣十分不方便，一是因?yàn)殄e(cuò)誤碼是和正常結(jié)果一樣的方式返回的，判斷起來(lái)十分不方便，二是錯(cuò)誤還需要一級(jí)一級(jí)的向上報(bào)，直到錯(cuò)誤處理程序。

所以高級(jí)語(yǔ)言通常都內(nèi)置了一套 try...except...finally... 的錯(cuò)誤處理機(jī)制，Python也不例外。

try:
  A#如果A中的代碼執(zhí)行過(guò)程中出錯(cuò)，就會(huì)執(zhí)行B中的代碼
except ZeroDivisionError as e:
  B
finally:
  C#C中的代碼無(wú)論是否出錯(cuò)都會(huì)正常執(zhí)行（可以不要這個(gè)）<br>。。。

如果錯(cuò)誤有不同的類型，可以說(shuō)使用多個(gè)except語(yǔ)句，每個(gè)語(yǔ)句處理一個(gè)類型的錯(cuò)誤

另外，可以在except后面加一個(gè)else，如果沒有出錯(cuò)，會(huì)執(zhí)行else

Python 的錯(cuò)誤其實(shí)也是一個(gè)類，所有的異常類型都是從BaseException類派生的

except在捕獲錯(cuò)誤時(shí)，不但捕獲該類型的錯(cuò)誤，而且還會(huì)把子類一網(wǎng)打盡

try:
  foo()
except ValueError as e:
  print('ValueError')
except UnicodeError as e:
  print('UnicodeError')
#第二個(gè)except永遠(yuǎn)也捕獲不到UnicodeError，因?yàn)閁nicodeError是ValueError的子類，如果有，也被第一個(gè)except給捕獲了。

使用try...except還有一個(gè)巨大的好處，就是可以跨越多層調(diào)用，比如函數(shù)main()調(diào)用foo()，foo()調(diào)用bar()，結(jié)果bar()出錯(cuò)了，這時(shí)，只要main()捕獲到了，就可以處理。也就是說(shuō)，不需要在每個(gè)可能出錯(cuò)的地方去捕獲錯(cuò)誤，只要在合適的層次去捕獲錯(cuò)誤就可以了。這樣一來(lái)，就大大減少了寫try...except...finally的麻煩。

記錄錯(cuò)誤

如果不捕獲錯(cuò)誤，自然可以讓Python解釋器來(lái)打印出錯(cuò)誤堆棧，但程序也被結(jié)束了。既然我們能捕獲錯(cuò)誤，就可以把錯(cuò)誤堆棧打印出來(lái)，然后分析錯(cuò)誤原因，同時(shí)，讓程序繼續(xù)執(zhí)行下去。

Python內(nèi)置的logging模塊可以非常容易地記錄錯(cuò)誤信息

通過(guò)配置，logging還可以把錯(cuò)誤記錄到日志文件里，方便事后排查。

拋出錯(cuò)誤

因?yàn)殄e(cuò)誤是class，捕獲一個(gè)錯(cuò)誤就是捕獲到該class的一個(gè)實(shí)例。因此，錯(cuò)誤并不是憑空產(chǎn)生的，而是有意創(chuàng)建并拋出的。Python的內(nèi)置函數(shù)會(huì)拋出很多類型的錯(cuò)誤，我們自己編寫的函數(shù)也可以拋出錯(cuò)誤。

如果要拋出錯(cuò)誤，首先根據(jù)需要，可以定義一個(gè)錯(cuò)誤的class，選擇好繼承關(guān)系，然后，用raise語(yǔ)句拋出一個(gè)錯(cuò)誤的實(shí)例

只有在有必要的時(shí)候才定義我們自己的錯(cuò)誤

另外一種錯(cuò)誤處理

在try...excep捕獲到異常后，還可以在except中使用 'raise‘把異常拋出去，以便于上級(jí)處理，如果raise語(yǔ)句不帶參數(shù)，就會(huì)把異常原樣拋出去，我們還可以通過(guò)raise 跟一個(gè)別的異常類型來(lái)將一種錯(cuò)誤的類型轉(zhuǎn)化為另外一種類型如：

try:
  10 / 0
except ZeroDivisionError:
  raise ValueError('input error!')

這種類型應(yīng)該是一種合理的類型，而不應(yīng)該將一種類型轉(zhuǎn)化為另外一種不相干的類型

程序也可以主動(dòng)拋出錯(cuò)誤，讓調(diào)用者來(lái)處理相應(yīng)的錯(cuò)誤。但是，應(yīng)該在文檔中寫清楚可能會(huì)拋出哪些錯(cuò)誤，以及錯(cuò)誤產(chǎn)生的原因?！　?/p>

調(diào)試

斷言

我們有事再調(diào)試的時(shí)候?yàn)榱耸∈拢椭苯佑蓀rint打印出變量的值，斷言的作用和上面一樣，凡是可以用print來(lái)輔助查看的地方，都可以用斷言替代

斷言可以加提示信息，

def foo(s):
  n = int(s)
  assert n != 0, 'n is zero!'#檢查n是否是0，返回bool
  return 10 / n
 
def main():
  foo('0')

如果斷言失敗，assert語(yǔ)句本身就會(huì)拋出AssertionError：提示信息

啟動(dòng)Python解釋器時(shí)可以用-O參數(shù)來(lái)關(guān)閉assert：

$ python -O err.py

使用pdb方式來(lái)調(diào)試

python -m pdb fortest.py#使用-m pdb 來(lái)啟動(dòng)調(diào)試
l #使用l來(lái)查看代碼
n #使用n來(lái)執(zhí)行一行代碼
p 變量名#任何時(shí)候都可以輸入p加變量名來(lái)查看變量
q#使用q退出

pdb.set_trace()

這個(gè)方法也是用pdb，但是不需要單步執(zhí)行，我們只需要import pdb，然后，在可能出錯(cuò)的地方放一個(gè)pdb.set_trace()，就可以設(shè)置一個(gè)斷點(diǎn)：

運(yùn)行代碼，程序會(huì)自動(dòng)在pdb.set_trace()暫停并進(jìn)入pdb調(diào)試環(huán)境，可以用命令p查看變量，或者用命令c繼續(xù)運(yùn)行：

IDE

雖然用IDE調(diào)試起來(lái)比較方便，但是最后你會(huì)發(fā)現(xiàn)，logging才是終極武器。

單元測(cè)試

為什么編寫單元測(cè)試呢，因?yàn)樵趯懞玫某绦蚩赡茉谝院筮€需要修改，這時(shí)如果由單元測(cè)試，我們就能夠保證修改后的程序在功能上和以前的相同，這一定程度上也減少了測(cè)試的繁雜性

這種以測(cè)試為驅(qū)動(dòng)的開發(fā)模式最大的好處就是確保一個(gè)程序模塊的行為符合我們?cè)O(shè)計(jì)的測(cè)試用例。在將來(lái)修改的時(shí)候，可以極大程度地保證該模塊行為仍然是正確的。

接下來(lái)，作者舉了一個(gè)例子來(lái)介紹了單元測(cè)試的編寫模式，并且介紹了一些用到的函數(shù)

我們需要引入Python自帶的測(cè)試模塊unittest模塊

import unittest

編寫單元測(cè)試的時(shí)候，需要編寫一個(gè)測(cè)試類，這個(gè)類從unittest.TestCase派生

def TestDict(unittest.TestCase):
  def test_init(self):
    pass

以test開頭的方法就是測(cè)試方法，不以test開頭的方法就不被認(rèn)為是測(cè)試方法，運(yùn)行單元測(cè)試的時(shí)候不會(huì)被執(zhí)行

對(duì)每一類測(cè)試都需要編寫一個(gè)測(cè)試方法，由于unittest.TestCase內(nèi)置了很多判斷，我們只需要斷言這些輸出是否是我們所需要的，最常用的斷言就是assertEqual(),

self.assertEqual(abs(-1), 1) # 斷言函數(shù)返回的結(jié)果與1相等
另一種重要的斷言就是期待拋出指定類型的Error，比如通過(guò)d['empty']訪問不存在的key時(shí)，斷言會(huì)拋出KeyError：

with self.assertRaises(KeyError):
  value = d['empty']

運(yùn)行單元測(cè)試

兩種方法，一種直接在模塊中加入

if __name__ == '__main__':
unittest.main()

另一種方法是在命令行通過(guò)參數(shù)-m unittest直接運(yùn)行單元測(cè)試

這是推薦的做法，因?yàn)檫@樣可以一次批量運(yùn)行很多單元測(cè)試，并且，有很多工具可以自動(dòng)來(lái)運(yùn)行這些單元測(cè)試。

setUp和tearDown

這兩個(gè)函數(shù)可以寫在測(cè)試類中，作用就是再每個(gè)測(cè)試方法被調(diào)用之前會(huì)執(zhí)行setUp（），被調(diào)用之后會(huì)執(zhí)行tearDown()，可以把一些準(zhǔn)備工作、和善后工作放到這些函數(shù)中。

• 單元測(cè)試可以有效地測(cè)試某個(gè)程序模塊的行為，是未來(lái)重構(gòu)代碼的信心保證。
• 單元測(cè)試的測(cè)試用例要覆蓋常用的輸入組合、邊界條件和異常。
• 單元測(cè)試代碼要非常簡(jiǎn)單，如果測(cè)試代碼太復(fù)雜，那么測(cè)試代碼本身就可能有bug。
• 單元測(cè)試通過(guò)了并不意味著程序就沒有bug了，但是不通過(guò)程序肯定有bug。

文檔測(cè)試

文檔測(cè)試就是運(yùn)行寫在注釋中的實(shí)例代碼

文檔測(cè)試不能再調(diào)試（Debugger）模式下運(yùn)行，否則會(huì)報(bào)錯(cuò)

PYDEV DEBUGGER WARNING:
sys.settrace() should not be used when the debugger is being used.
This may cause the debugger to stop working correctly.
If this is needed, please check:
http://pydev.blogspot.com/2007/06/why-cant-pydev-debugger-work-with.html
to see how to restore the debug tracing back correctly.
Call Location:
 File "c:\users\administrator.sc-201605202132\appdata\local\programs\python\python36\Lib\doctest.py", line 1480, in run
  sys.settrace(save_trace)

很多文檔都有示例代碼，可以把這些示例代碼在Python的交互環(huán)境下運(yùn)行。這些代碼與其他說(shuō)明可以寫在注釋中，然后，由一些工具來(lái)自動(dòng)生成文檔

def abs(n):
  '''
  Function to get absolute value of number.
   
  Example:
   
  >>> abs(1)
  1
  >>> abs(-1)
  1
  >>> abs(0)
  0
  '''
  return n if n >= 0 else (-n)

無(wú)疑更明確地告訴函數(shù)的調(diào)用者該函數(shù)的期望輸入和輸出。并且，Python內(nèi)置的“文檔測(cè)試”（doctest）模塊可以直接提取注釋中的代碼并執(zhí)行測(cè)試。

doctest嚴(yán)格按照Python交互式命令行的輸入和輸出來(lái)判斷測(cè)試結(jié)果是否正確。只有測(cè)試異常的時(shí)候(即真正運(yùn)行的結(jié)果和實(shí)例代碼中的結(jié)果不一樣的時(shí)候，就會(huì)報(bào)錯(cuò)），可以用...表示中間一大段煩人的輸出。

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評(píng)論