The art of readable code摘要 -- 特定題材

testing and readability (測試以及可靠性)
make tests easy to read and maintain (讓測試容易理解及維護)
測試可以讓人勇敢的修改程式碼，所以可以提升維護性

what’s wrong with this test? (測試發生了甚麼事?)
舉例下面的測試，並且慢慢修正

void Test1() {
    vector<ScoredDocument> docs;
    docs.resize(5);
    docs[0].url = "http://example.com";
    docs[0].score = -5.0;
    docs[1].url = "http://example.com";
    docs[1].score = 1;
...

 SortAndFilterDocs(&docs);
    assert(docs.size() == 3);
    assert(docs[0].score == 4);
    assert(docs[1].score == 3.0);
    assert(docs[2].score == 1);
}



making this test more readable (讓測試更具備可讀性)
文章建議將docs[0].property=xxx，包裹成function，命名為類似addDoc()比較有可讀性，更進一步或許可以建立起string to docs的function，方便產生資料

making error messages readable (使錯誤訊息更具備可讀性)
建議assert錯誤的時候可以輸出更有用的訊息

choosing good test inputs (選擇一個恰當的輸入)
建議簡化以及多種的輸入，做到良好的測試

naming test functions (為測試函數命名)
Test1沒有意義，測試命名要有意義

what was wrong with that test? (測試發生了甚麼事?)
回顧前面的問題

test-friendly development (友善的測試開發)
作者同意TDD (Test Driven Development)的基本想法，並且列出了許多有問題的特徵

going too far (想太多)
作者列出三點可能想太多的盲點

• Sacrificing the readability of your real code, for the sake of enabling tests.
• Being obsessive about 100% test coverage.
• Letting testing get in the way of product development.

designing and implementing a “minute/hour counter” (實作 分鐘/小時 計數器)
the problem
defining the class interface
作者做一總結回顧，舉例以及技巧應用

================我的心得================
可以比較依些類似unit test的構想，以及M$談論測試的書籍，會發現測試真的是一個專門的事情，好比光100% coverage，在M$上是"必須"達到的事情，此外agile process有些建議則是不應該花太多精神在"照顧"test，test應該保持直觀、快速開發，比方說將docs[0].property=xxx包裝成為函數，可能就不大受歡迎，因為可能引入更多的bug，又要花更多時間去維護test，頗有得不償失的味道