學習式測試

邊界，指的是程式與程式的交界處，而處理好邊界，是優秀程式碼不可或缺的環節。當我們提到程式與程式的交界時，很直覺地會聯想到第三方套件、介面 (interface)、API 等名詞。是的，這些的確很常就是需要被處理的邊界。

學習第三方套件並不容易，將其整合進自己的程式碼更是加倍困難。而其中有一種探索與瞭解第三方軟體的模式，叫做學習式測試。

學習式測試，是照著原本在應用程式裡呼叫第三方軟體的方法，去為這個 API 寫測試。但這個測試所要確認的不是套件的程式邏輯────那顯然不是我們的職責────而是檢視我們對於第三方套件的認識程度。

這個測試的重點在於，我們想要從 API 獲得什麼樣的結果。

邊界測試

在使用第三方套件前，我們本就要先去學習如何呼叫其 API，而藉著寫出測試內容去驗證，我們可以很直觀地發現我們對於套件的理解是否有誤。若錯了能馬上從測試反饋學到真正的使用結果，而對了我們則能確定該 API 的用法。由於我們本來就無法跳過學習的過程，所以實質上並沒有多花太多時間。

而更重要的是，藉由邊界測試，我們將可以避開套件版本更新的風險。當新版本無法通過測試時，我們能馬上發現問題並調整，大幅提升整合的時間。

使用尚未存在的程式

還有另一種邊界，一種將已知和未知分開的邊界。

在中、大型專案撰寫軟體時，往往是許多人一同協作完成，也因此當我們在開發軟體時，許多時候另一個與我們相關聯的程式或子系統，還並沒有被開發出來。自然地，串接的 API 也還不會被定義、設計。

在這種情形下，為了不讓自己的開發被困住，我們會界定出一個彼此的邊界，使我們知道我們將可以開發到哪個位置。這個邊界就是一個介面。當我們定義出所希望擁有的介面樣式時，我們也同時擁有了主控權。

小結

當我閱讀這篇文章時，深有所感。不知是否因為自己是從 JavaScript 開始接觸程式，鮮少使用介面，對介面的敏銳度也非常低。是以我從沒意識到邊界的存在，也從未替自己的程式立下過邊界。縱然在串接 API 時，遇到資料耦合過高的困難，也未曾想過可以如何改變，直到今天才被點醒。

但今天醒過來，應也不晚吧。