當(dāng)我加入Ansible團(tuán)隊(duì)之后，我決定寫下多年來所學(xué)到的軟件工程實(shí)踐和原理方面的經(jīng)驗(yàn)。我的激情是測(cè)試，因?yàn)槲蚁嘈帕己玫臏y(cè)試既可以確保最低質(zhì)量標(biāo)準(zhǔn)(可惜很多軟件產(chǎn)品都缺乏這一點(diǎn))，也可以指導(dǎo)和塑造開發(fā)過程本身。以下許多建議與測(cè)試有關(guān)，其中一些原則甚至特定于Python，但絕大多數(shù)不是。(對(duì)于Python程序員，PEP 8應(yīng)該是編程風(fēng)格和指南的第一站。)

1、不要編寫你認(rèn)為以后可能需要但目前不需要的代碼。這是對(duì)未來想象的用例的編碼，并且這種代碼一定會(huì)成為死碼或需要重寫，因?yàn)槲磥淼挠美偸桥c程序員的想象略有不同。

注釋代碼也是如此，如果一段注釋的代碼正在進(jìn)行發(fā)布，它不應(yīng)該存在。YAGNI是編程的核心要素，最佳參考資料是極限編程解析(Extreme Programming Explained)。

2、不進(jìn)行多余的測(cè)試。基礎(chǔ)設(shè)施，框架和庫(kù)是需要測(cè)試的，不要測(cè)試瀏覽器或外部庫(kù)，除非你真的需要。測(cè)試你自己編寫的代碼，而不是其他人寫的代碼。

3、多次重復(fù)出現(xiàn)的代碼不需要測(cè)試。輔助功能不需要測(cè)試，當(dāng)你把它們分開并重新使用時(shí)，需要測(cè)試。如果反復(fù)編寫類似代碼多次時(shí)，您通常會(huì)很清楚正在解決的問題。

4、關(guān)于API設(shè)計(jì)(外部面向?qū)ο驛PI)：簡(jiǎn)單的事情盡量簡(jiǎn)單完成，復(fù)雜的事情盡力優(yōu)化。首先為簡(jiǎn)單案例設(shè)計(jì)，如果可能的話，優(yōu)選為零配置或參數(shù)化。Addoptions或附加的API方法，用于更復(fù)雜和更靈活的用例(根據(jù)需要)。

5、盡早檢查無意義的輸入或無效狀態(tài)，最好是異常或錯(cuò)誤響應(yīng)，這將使程序員很清楚問題的確切信息。(除非真的需要，否則不要進(jìn)行輸入驗(yàn)證類型的檢查)。

6、在可能的情況下，將測(cè)試對(duì)象視為黑盒子，通過公共API進(jìn)行測(cè)試，這就不需要調(diào)用私有方法或修改狀態(tài)。

對(duì)于一些復(fù)雜的場(chǎng)景，編寫測(cè)試真的是有幫助的，因?yàn)檫@迫使程序員考慮代碼的行為以及在編寫代碼之后如何進(jìn)行測(cè)試。測(cè)試首先鼓勵(lì)更小、更模塊化的代碼單元，這通常意味著更好的代碼。

7、對(duì)于單元測(cè)試(包括基礎(chǔ)架構(gòu)測(cè)試)，應(yīng)測(cè)試所有代碼路徑。 100%的覆蓋是一個(gè)良好的開端。除非你無法覆蓋所有可能的排列/組合的狀態(tài)，只有一個(gè)非常好的理由才能使代碼路徑不全部經(jīng)過測(cè)試，以時(shí)間為借口早晚會(huì)浪費(fèi)更多時(shí)間。

8、代碼是敵人：可能出錯(cuò)，需要維護(hù)。盡量有更少的代碼實(shí)現(xiàn)必需的功能，刪除不必要的代碼。

9、努力通過良好的命名規(guī)范和已知的編程風(fēng)格使代碼可讀和形成自我記錄。通常隨著時(shí)間的推移，很多程序員都不認(rèn)識(shí)自己寫的代碼了。

10、代碼注釋——對(duì)一些無法明確的代碼，請(qǐng)盡早提供注釋，說明為什么要這么寫，有無其他方法等。

11、編碼過程中務(wù)必想想可能出現(xiàn)的問題，無效輸入會(huì)發(fā)生什么，哪些情況會(huì)導(dǎo)致失敗，這將有助于程序員在發(fā)生錯(cuò)誤之前捕獲更多錯(cuò)誤。

12、簡(jiǎn)單的邏輯易進(jìn)行單元測(cè)試，將邏輯分解為單獨(dú)的函數(shù)，而不是將邏輯混合為有狀態(tài)和有副作用填充代碼。(測(cè)試的開銷越少意味著測(cè)試更快)。

13、使用對(duì)象可能比使用復(fù)雜的數(shù)據(jù)結(jié)構(gòu)更好。使用Python的內(nèi)置類型及其方法將比編寫自己的類型更快(除非您在C中編寫)。如果考慮性能，請(qǐng)嘗試了解如何使用標(biāo)準(zhǔn)內(nèi)置類型而不是自定義對(duì)象。

14、依賴注入是一個(gè)有用的編碼模式，用于程序員搞清楚依賴關(guān)系以及它們來自哪里(有對(duì)象，方法等作為參數(shù)接收它們的依賴關(guān)系，而不是實(shí)例化新對(duì)象本身)。關(guān)于依賴注入的文章可參考Martin Fowler的“Inversion of Control Containers and the Dependency Injection Pattern”。

15、代碼越多，代碼越差。程序員的目標(biāo)應(yīng)該是小型的可測(cè)試單元，以及更高級(jí)的集成和功能測(cè)試，以測(cè)試單元是否正確合作。

16、設(shè)計(jì)API時(shí)應(yīng)該考慮到以后可能會(huì)遇到的更改，并考慮到未來的用例——真的很重要。改變API對(duì)程序員和用戶而言都是一種痛苦，并且創(chuàng)建向后的不兼容性是可怕的(盡管有時(shí)不可避免)。

17、如果函數(shù)或方法超過30行代碼，請(qǐng)考慮將其分解。最大模塊尺寸為500行，測(cè)試文件往往比這更長(zhǎng)。

18、不要在對(duì)象構(gòu)造函數(shù)中工作，這很難測(cè)試。不要將代碼放在__init__.py中(除了用于命名空間的導(dǎo)入)。 __init__.py不是程序員通常期望找到代碼的地方。

19、在測(cè)試中，單個(gè)測(cè)試文件的可讀性比可維護(hù)性更重要(打破可重用的塊)。這是因?yàn)闇y(cè)試被單獨(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)和測(cè)試的書是Michael Feathers的Working Effectively with Legacy Code。

21、在處理性能問題時(shí)，請(qǐng)務(wù)必在修復(fù)之前進(jìn)行配置。如果你已經(jīng)剖析并證明代碼實(shí)際上是值得的，編寫一個(gè)測(cè)試隨時(shí)對(duì)代碼進(jìn)行分析，并且保留在測(cè)試套件中以防止性能回歸。(添加時(shí)間碼總是會(huì)改變代碼的性能特征，使性能成為更令人沮喪的任務(wù)之一)。

22、更小，更嚴(yán)格的單位測(cè)試在失敗時(shí)提供更有價(jià)值的信息。通常，運(yùn)行超過0.1秒的測(cè)試不是單元測(cè)試。單元測(cè)試可以提供更具體的錯(cuò)誤信息，關(guān)于單元測(cè)試實(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