單元測試框架進行自動化測試

單元測試框架進行自動化測試

到底單元測試是作什麼用的？單元測試是一種測試，它不是代碼的一部分；單元測試是最低層級的測試，它只保證函數的可靠性，不保證其它；單元測試應該能保證每個函數的可靠性。

單元測試是一種測試，因此，咱們應該以一種測試的眼光去面對它——咱們要測試正常狀況，邊界條件，要對它的測試目標——函數作黑盒分析，白盒分析，選擇合適的測試數據，構建測試場景和測試環境——總之，一切測試應該作的事情，單元測試都不該該省略。

理論上來講，單元測試和其餘測試同樣，也是能夠純手工完成的：咱們能夠寫一段某函數的測試代碼，而後輸入咱們的測試輸入，觀察測試輸出，並跟指望值作比較——事實上這種人工測試，寫了一段時間代碼的人應該都不會陌生。可是，單元測試有一點特殊性，就是在一個系統中，函數會很是很是的多，變化也比軟件的功能頻繁的多。面對這麼多的函數，這麼頻繁的變化，純手工測試是不現實的。因此，咱們必需要引入單元測試框架進行自動化測試。注意，這裏的單元測試框架只是實現自動化測試的一個手段，對單元測試自己並不產生任何影響——沒有單元測試框架，單元測試同樣也是能夠進行的，只是會痛苦不少。

單元測試框架引入的目的只是爲了自動化單元測試，簡化單元測試的步驟。因此，對於測試代碼的編寫，重點應該是：如何搭建測試環境、測試場景；如何選擇測試用例；如何校驗測試結果。對於測試代碼自己，應該儘量的簡單，能不要使用技巧儘可能不要使用，目的在於測試，若是測試自己過於複雜，咱們不能保證測試的正確性，測試這個工做就白作了。

剛剛提到單元測試是對函數的測試，所以，測試必須是以函數爲單位的。每一個函數應該擁有本身單獨的一個測試，這個測試中，應該針各個方面進行完善的測試，這樣咱們才能保證這個函數的功能是如咱們所願的。可是單元測試不須要負責函數的組合工做狀況。那應該是功能測試的工做，而不是單元測試的工做。如作app功能測試，這個功能測試就是在假定全部函數都工做正常的基礎之上，對這些函數組合造成的功能模塊進行測試。這種測試，視狀況而定，可使用單元測試框架，也可使用其餘自動化測試方法或者甚至是使用純人工測試。