知識星球
當我加入Ansible團隊之後，我決定寫下多年來所學到的軟體工程實踐和原理方面的經驗。我的激情是測試，因為我相信良好的測試既可以確保最低質量標準(可惜很多軟體產品都缺乏這一點)，也可以指導和塑造開發過程本身。以下許多建議與測試有關，其中一些原則甚至特定於Python，但絕大多數不是。(對於Python程式員，PEP 8應該是程式設計風格和指南的第一站。)
1、不要編寫你認為以後可能需要但目前不需要的程式碼。這是對未來想象的用例的編碼，並且這種程式碼一定會成為死碼或需要重寫，因為未來的用例總是與程式員的想象略有不同。
註釋程式碼也是如此，如果一段註釋的程式碼正在進行釋出，它不應該存在。YAGNI是程式設計的核心要素，最佳參考資料是極限程式設計解析(Extreme Programming Explained)。
2、不進行多餘的測試。基礎設施，框架和庫是需要測試的，不要測試瀏覽器或外部庫，除非你真的需要。測試你自己編寫的程式碼，而不是其他人寫的程式碼。
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
宣告：文章著作權歸作者所有，如有侵權，請聯絡小編刪除
