程式碼整潔之道
簡介：
本書是程式設計大師“Bob 大叔”40餘年程式設計生涯的心得體會的總結，講解要成為真正專業的程式設計師需要具備什麼樣的態度，需要遵循什麼樣的原則，需要採取什麼樣的行動。作者以自己以及身邊的同事走過的彎路、犯過的錯誤為例，意在為後來者引路，助其職業生涯邁上更高臺階。
本書適合所有程式設計師閱讀，也可供所有想成為具備職業素養的職場人士參考。
第七章 驗收測試
專業開發人員既要做好開發，也要做好溝通。“輸入糟糕，輸出也會糟糕”對程式設計師同樣適用，所以職業程式設計師會重視與團隊及業務部門的溝通，確保這種溝通的準確、流暢。
7.1 需求的溝通
過早精細化
做業務的人和寫程式的人都容易陷入一個陷阱，即過早進行精細化。業務方還沒有啟動專案，就要精確知道最後能得到什麼；開發方還沒有評估整個專案，就希望精確知道要交付什麼。雙方都貪求不現實的精確性，而且經常願意花大價錢來追求這種精確。
不確定性：
在工作中，有一種現象叫觀察者效應，或者不確定原則。每次你向業務方展示一項功能，他們就獲得了比之前更多的資訊，這些新資訊反過來又會影響他們對整個系統的看法。
預估焦慮：需求是一定會變化的，所以追求那種精確性是徒勞的。
遲來的模糊性：
避免過早精細化的辦法是儘可能地推遲精細化。專業開發人員直到著手開發的前一刻才會把需求具體化。但是，這可能造成另一個問題：遲來的模糊性。
需求文件中的每一點模糊之處，都對應著業務方的一點分歧。當然，模糊不只來自於分歧或爭論。有時候，業務方會想當然地認為看文件的人懂得自己的意思
7.2 驗收測試
在本章，我們把驗收測試定義為業務方與開發方合作編寫的測試，其目的在於確定需求已經完成。
”完成“的定義
完成意味著所有的程式碼都寫完了，所有的測試都透過了，QA和需求方已經認可。這，才是完成。
那麼，怎樣能達到這種程度的完成，同時不影響迭代的速度呢？你應該編寫整套的自動化測試，它們全都透過，就意味著滿足了所有的要求。如果對功能的驗收測試全部透過，就算真正完成了。專業開發人員會根據自動化的驗收測試來定義需求。他們與業務方和QA一起工作，確保自動化測試能夠真正覆蓋完成所需的各項指標。
溝通：
驗收測試的目的是溝通、澄清、精確化。開發方、業務方、測試方對驗收測試達成共識，大家都能明白系統的行為將會是怎樣。各方都應當記錄這種準確的共識。在專業開發人員看來，與業務方、測試方協同工作，確保大家都明白要做的是什麼，是自己的責任。
自動化：專業程式設計師會避免這種情況。相比手動測試，自動化測試的成本非常低，讓人手工執行測試指令碼不划算。專業開發人員認為，實現驗收測試的自動化是自己的責任。
專業開發人員對待自動化這種額外工作的態度：
寫這麼多測試，看起來的確是大量額外工作。這根本不是什麼額外工作。
寫這些測試是為了確定系統的各項指標符合要求。確定這些細節指標的目的，是為了確定系統的指標；只有確定這些細節指標，我們這些程式設計師才能確知“完成”；只有確定這些細節指標，業務方才能確認他們花錢開發的系統確實滿足了需求；只有確認這些指標，才可以真正做到自動化測試。
所以，不要把它們看作額外的工作，而應當看成節省時間和金錢的辦法。這些測試可以避免你的開發誤入歧途，也可以幫你確認自己已經完工。
驗收測試什麼時候寫，由誰來寫：
通常會把測試交給業務分析員、QA甚至是開發人員。如果只能由開發人員來寫測試，應當確保寫測試的程式設計師與開發所測試功能的程式設計師不是同一個人。
通常，業務分析員測試“正確路徑”，以證明功能的業務價值；QA則測試“錯誤路徑”、邊界條件、異常、例外情況，因為QA的職責是考慮哪些部分可能出問題。
遵循“推遲精細化”的原則，驗收測試應該越晚越好，通常是功能執行完成的前幾天。在敏捷專案中，只有在選定了下一輪迭代（Iteration）或當前衝刺（Sprint）所需要的功能之後，才編寫測試。
開發人員的角色：開發人員有責任把驗收測試與系統聯絡起來，然後讓這些測試透過。
- 身為專業開發人員，與編寫測試的人協商並改進測試是你的職責。絕不能被動接受測試，更不能對自己說：“噢，測試是這麼要求的，我就得這麼辦。
- ”請記住，身為專業開發人員，你的職責是協助團隊開發出最棒的軟體。也就是說，每個人都需要關心錯誤和疏忽，並協力改正。
驗收測試和單元測試區別：
首先，儘管兩者測試的可能是同一個物件，其機制和路徑卻是不同的。單元測試是深入系統內部進行，呼叫特定類的方法；驗收測試則是在系統外部，通常是在API或者是UI級別進行。所以兩者的執行路徑是截然不同的。
它們的主要功能其實不是測試，測試只是它們的附屬職能。單元測試和驗收測試首先是文件，然後才是測試。它們的主要目的是如實描述系統的設計、結構、行為。它們當然可以驗證設計、結構、行為是否達到了具體指標，但是，它們的真正價值不在測試上，而在具體指標上。
圖形介面：
- 更好的辦法是，測試系統功能時，應當呼叫真實的API，而不是GUI。
- 幾十年來，設計專家一直在教導我們，要把GUI和業務邏輯分開。
持續整合：
請務必確保在持續整合系統中，單元測試和驗收測試每天都能執行好幾次。整套持續整合系統應該由原始碼管理系統來觸發。只要有人提交了程式碼，持續整合系統就會開始構建，並執行所有的測試，測試結果會用電子郵件傳送給團隊所有人。
持續整合不應該失敗，如果失敗了，團隊裡的所有人都應該停下手裡的活，看看如何讓測試透過。在持續整合系統裡，失敗的整合應該視為緊急情況，也就是“立刻中止”型事件。
結論
交流細節資訊是件麻煩事。尤其是開發方和業務方交流關於程式的細節時，更是如此。通常，各方握手言歡，以為其他人都明白自己的意思。雙方以為取得了共識，然後帶著截然不同的想法離開，這種事太平常不過了。
要解決開發方和業務方溝通問題，我所知道的唯一有效的辦法就是編寫自動化的驗收測試。這些測試足夠正式，所以其結果有權威性。這些測試不會造成模糊，也不可能與真實系統脫節。它們，就是無可挑剔的需求文件。