資深程序員：給Python軟件開發(fā)測試的25個(gè)忠告！
2018-07-20 來源：編程學(xué)習(xí)網(wǎng)
當(dāng)我加入Ansible團(tuán)隊(duì)之后，我決定寫下多年來所學(xué)到的軟件工程實(shí)踐和原理方面的經(jīng)驗(yàn)。我的激情是測試，因?yàn)槲蚁嘈帕己玫臏y試既可以確保最低質(zhì)量標(biāo)準(zhǔn)(可惜很多軟件產(chǎn)品都缺乏這一點(diǎn))，也可以指導(dǎo)和塑造開發(fā)過程本身。以下許多建議與測試有關(guān)，其中一些原則甚至特定于Python，但絕大多數(shù)不是。(對于Python程序員，PEP 8應(yīng)該是編程風(fēng)格和指南的第一站。)
1、不要編寫你認(rèn)為以后可能需要但目前不需要的代碼。這是對未來想象的用例的編碼，并且這種代碼一定會成為死碼或需要重寫，因?yàn)槲磥淼挠美偸桥c程序員的想象略有不同。
注釋代碼也是如此，如果一段注釋的代碼正在進(jìn)行發(fā)布，它不應(yīng)該存在。YAGNI是編程的核心要素，最佳參考資料是極限編程解析(Extreme Programming Explained)。
2、不進(jìn)行多余的測試�；A(chǔ)設(shè)施，框架和庫是需要測試的，不要測試瀏覽器或外部庫，除非你真的需要。測試你自己編寫的代碼，而不是其他人寫的代碼。
3、多次重復(fù)出現(xiàn)的代碼不需要測試。輔助功能不需要測試，當(dāng)你把它們分開并重新使用時(shí)，需要測試。如果反復(fù)編寫類似代碼多次時(shí)，您通常會很清楚正在解決的問題。
4、關(guān)于API設(shè)計(jì)(外部面向?qū)ο驛PI)：簡單的事情盡量簡單完成，復(fù)雜的事情盡力優(yōu)化。首先為簡單案例設(shè)計(jì)，如果可能的話，優(yōu)選為零配置或參數(shù)化。Addoptions或附加的API方法，用于更復(fù)雜和更靈活的用例(根據(jù)需要)。
5、盡早檢查無意義的輸入或無效狀態(tài)，最好是異�；蝈e(cuò)誤響應(yīng)，這將使程序員很清楚問題的確切信息。(除非真的需要，否則不要進(jìn)行輸入驗(yàn)證類型的檢查)。
6、在可能的情況下，將測試對象視為黑盒子，通過公共API進(jìn)行測試，這就不需要調(diào)用私有方法或修改狀態(tài)。
對于一些復(fù)雜的場景，編寫測試真的是有幫助的，因?yàn)檫@迫使程序員考慮代碼的行為以及在編寫代碼之后如何進(jìn)行測試。測試首先鼓勵(lì)更小、更模塊化的代碼單元，這通常意味著更好的代碼。
7、對于單元測試(包括基礎(chǔ)架構(gòu)測試)，應(yīng)測試所有代碼路徑。 100%的覆蓋是一個(gè)良好的開端。除非你無法覆蓋所有可能的排列/組合的狀態(tài)，只有一個(gè)非常好的理由才能使代碼路徑不全部經(jīng)過測試，以時(shí)間為借口早晚會浪費(fèi)更多時(shí)間。
8、代碼是敵人：可能出錯(cuò)，需要維護(hù)。盡量有更少的代碼實(shí)現(xiàn)必需的功能，刪除不必要的代碼。
9、努力通過良好的命名規(guī)范和已知的編程風(fēng)格使代碼可讀和形成自我記錄。通常隨著時(shí)間的推移，很多程序員都不認(rèn)識自己寫的代碼了。
10、代碼注釋——對一些無法明確的代碼，請盡早提供注釋，說明為什么要這么寫，有無其他方法等。
11、編碼過程中務(wù)必想想可能出現(xiàn)的問題，無效輸入會發(fā)生什么，哪些情況會導(dǎo)致失敗，這將有助于程序員在發(fā)生錯(cuò)誤之前捕獲更多錯(cuò)誤。
12、簡單的邏輯易進(jìn)行單元測試，將邏輯分解為單獨(dú)的函數(shù)，而不是將邏輯混合為有狀態(tài)和有副作用填充代碼。(測試的開銷越少意味著測試更快)。
13、使用對象可能比使用復(fù)雜的數(shù)據(jù)結(jié)構(gòu)更好。使用Python的內(nèi)置類型及其方法將比編寫自己的類型更快(除非您在C中編寫)。如果考慮性能，請嘗試了解如何使用標(biāo)準(zhǔn)內(nèi)置類型而不是自定義對象。
14、依賴注入是一個(gè)有用的編碼模式，用于程序員搞清楚依賴關(guān)系以及它們來自哪里(有對象，方法等作為參數(shù)接收它們的依賴關(guān)系，而不是實(shí)例化新對象本身)。關(guān)于依賴注入的文章可參考Martin Fowler的“Inversion of Control Containers and the Dependency Injection Pattern”。
15、代碼越多，代碼越差。程序員的目標(biāo)應(yīng)該是小型的可測試單元，以及更高級的集成和功能測試，以測試單元是否正確合作。
16、設(shè)計(jì)API時(shí)應(yīng)該考慮到以后可能會遇到的更改，并考慮到未來的用例——真的很重要。改變API對程序員和用戶而言都是一種痛苦，并且創(chuàng)建向后的不兼容性是可怕的(盡管有時(shí)不可避免)。
17、如果函數(shù)或方法超過30行代碼，請考慮將其分解。最大模塊尺寸為500行，測試文件往往比這更長。
18、不要在對象構(gòu)造函數(shù)中工作，這很難測試。不要將代碼放在__init__.py中(除了用于命名空間的導(dǎo)入)。 __init__.py不是程序員通常期望找到代碼的地方。
19、在測試中，單個(gè)測試文件的可讀性比可維護(hù)性更重要(打破可重用的塊)。這是因?yàn)闇y試被單獨(dú)執(zhí)行和讀取，而不是自己成為較大系統(tǒng)的一部分，顯然過多的重復(fù)意味著可以為了方便而創(chuàng)建可重復(fù)使用的組件，這不僅僅是生產(chǎn)問題。
20、盡可能使用重構(gòu)。編程是抽象的，越接近問題域，代碼越容易理解和維護(hù)。隨著系統(tǒng)的發(fā)展，用例的結(jié)構(gòu)需要改變和擴(kuò)展。一本關(guān)于重構(gòu)和測試的書是Michael Feathers的Working Effectively with Legacy Code。
21、在處理性能問題時(shí)，請務(wù)必在修復(fù)之前進(jìn)行配置。如果你已經(jīng)剖析并證明代碼實(shí)際上是值得的，編寫一個(gè)測試隨時(shí)對代碼進(jìn)行分析，并且保留在測試套件中以防止性能回歸。(添加時(shí)間碼總是會改變代碼的性能特征，使性能成為更令人沮喪的任務(wù)之一)。
22、更小，更嚴(yán)格的單位測試在失敗時(shí)提供更有價(jià)值的信息。通常，運(yùn)行超過0.1秒的測試不是單元測試。單元測試可以提供更具體的錯(cuò)誤信息，關(guān)于單元測試實(shí)踐一本不錯(cuò)的書是Gary Bernhardt的Fast Test, Slow Test。
23、遵循YAGNI原則：編寫我們需要的特定代碼，而不是不需要的、復(fù)雜性的通用代碼。
24、共享代碼所有權(quán)是目標(biāo)。不分享或許就發(fā)現(xiàn)不了更好的編寫方式，比如分享出來，大家集思廣益。
25、最后，可以告訴產(chǎn)品經(jīng)理或開發(fā)商，一味地增加功能并不是好事，確保核心功能的高效率工作就可以了。
來自：http://www.techug.com/post/25-advice-for-python-tester.html
標(biāo)簽： 代碼
版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。
