當我加入Ansible團隊之后，我決定寫下多年來所學到的軟件工程實踐和原理方面的經驗。我的激情是測試，因為我相信良好的測試既可以確保最低質量標準(可惜很多軟件產品都缺乏這一點)，也可以指導和塑造開發過程本身。以下許多建議與測試有關，其中一些原則甚至特定于Python，但絕大多數不是。(對于Python程序員，PEP 8應該是編程風格和指南的第一站。)

1、不要編寫你認為以后可能需要但目前不需要的代碼。這是對未來想象的用例的編碼，并且這種代碼一定會成為死碼或需要重寫，因為未來的用例總是與程序員的想象略有不同。

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

2、不進行多余的測試?；A設施，框架和庫是需要測試的，不要測試瀏覽器或外部庫，除非你真的需要。測試你自己編寫的代碼，而不是其他人寫的代碼。

3、多次重復出現的代碼不需要測試。輔助功能不需要測試，當你把它們分開并重新使用時，需要測試。如果反復編寫類似代碼多次時，您通常會很清楚正在解決的問題。

4、關于API設計(外部面向對象API)：簡單的事情盡量簡單完成，復雜的事情盡力優化。首先為簡單案例設計，如果可能的話，優選為零配置或參數化。Addoptions或附加的API方法，用于更復雜和更靈活的用例(根據需要)。

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

6、在可能的情況下，將測試對象視為黑盒子，通過公共API進行測試，這就不需要調用私有方法或修改狀態。

對于一些復雜的場景，編寫測試真的是有幫助的，因為這迫使程序員考慮代碼的行為以及在編寫代碼之后如何進行測試。測試首先鼓勵更小、更模塊化的代碼單元，這通常意味著更好的代碼。

7、對于單元測試(包括基礎架構測試)，應測試所有代碼路徑。 100%的覆蓋是一個良好的開端。除非你無法覆蓋所有可能的排列/組合的狀態，只有一個非常好的理由才能使代碼路徑不全部經過測試，以時間為借口早晚會浪費更多時間。

8、代碼是敵人：可能出錯，需要維護。盡量有更少的代碼實現必需的功能，刪除不必要的代碼。

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

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

11、編碼過程中務必想想可能出現的問題，無效輸入會發生什么，哪些情況會導致失敗，這將有助于程序員在發生錯誤之前捕獲更多錯誤。

12、簡單的邏輯易進行單元測試，將邏輯分解為單獨的函數，而不是將邏輯混合為有狀態和有副作用填充代碼。(測試的開銷越少意味著測試更快)。

13、使用對象可能比使用復雜的數據結構更好。使用Python的內置類型及其方法將比編寫自己的類型更快(除非您在C中編寫)。如果考慮性能，請嘗試了解如何使用標準內置類型而不是自定義對象。

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

15、代碼越多，代碼越差。程序員的目標應該是小型的可測試單元，以及更高級的集成和功能測試，以測試單元是否正確合作。

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

17、如果函數或方法超過30行代碼，請考慮將其分解。最大模塊尺寸為500行，測試文件往往比這更長。

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

19、在測試中，單個測試文件的可讀性比可維護性更重要(打破可重用的塊)。這是因為測試被單獨執行和讀取，而不是自己成為較大系統的一部分，顯然過多的重復意味著可以為了方便而創建可重復使用的組件，這不僅僅是生產問題。

20、盡可能使用重構。編程是抽象的，越接近問題域，代碼越容易理解和維護。隨著系統的發展，用例的結構需要改變和擴展。一本關于重構和測試的書是Michael Feathers的Working Effectively with Legacy Code。

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

22、更小，更嚴格的單位測試在失敗時提供更有價值的信息。通常，運行超過0.1秒的測試不是單元測試。單元測試可以提供更具體的錯誤信息，關于單元測試實踐一本不錯的書是Gary Bernhardt的Fast Test, Slow Test。

23、遵循YAGNI原則：編寫我們需要的特定代碼，而不是不需要的、復雜性的通用代碼。

24、共享代碼所有權是目標。不分享或許就發現不了更好的編寫方式，比如分享出來，大家集思廣益。

25、最后，可以告訴產品經理或開發商，一味地增加功能并不是好事，確保核心功能的高效率工作就可以了。

來自：http://www.techug.com/post/25-advice-for-python-tester.html