問題背景#

剛開始寫 unit test 時，可能會覺得不太自然。一個常見的困擾是：測試程式碼擋住了路。在專案中瀏覽時，你可能忘記自己看的是 test code 還是 production code。隨著測試程式碼越來越多，這個問題會更嚴重。

除非建立一些命名慣例（conventions），否則很容易被淹沒。

Class Naming Conventions#

Test Class 命名#

每個 production class 通常會有至少一個對應的 unit test class。常見慣例是在 class 名稱前加 Test 前綴或後加 Test 後綴：

• DBEngine → TestDBEngine 或 DBEngineTest

作者偏好使用 Test 後綴。在依字母排序的 IDE 中，每個 class 會緊鄰其對應的 test class，導航更方便。

Fake Class 命名#

測試中經常需要為 package 或 directory 中的協作者建立 fake class。作者使用 Fake 前綴：

• FakeAccountOwner
• FakeTransaction

這讓所有 fake 在字母排序中聚集在一起，但又與主要 class 有一定距離。

Testing Subclass 命名#

Testing subclass 是為了測試而建立的子類別——當你使用 Subclass and Override Method 技巧時會用到。命名慣例是加上 Testing 前綴：

• TestingCheckingAccount
• TestingSavingsAccount

完整範例#

一個小型會計系統 package 的目錄列表：

• CheckingAccount
• CheckingAccountTest
• FakeAccountOwner
• FakeTransaction
• SavingsAccount
• SavingsAccountTest
• TestingCheckingAccount
• TestingSavingsAccount

注意每個 production class 緊鄰其 test class，fake 聚集在一起，testing subclass 也聚集在一起。

作者對這些慣例並不教條化。重要的是人體工學（ergonomics）——在 class 和 test 之間來回導航是否方便。

Test Location#

同一目錄 vs. 分開目錄#

作者的預設假設是將 test code 和 production code 放在同一目錄中。這是組織專案最簡單的方式，但需要考慮以下因素。

部署大小考量#

• 伺服器端應用程式：通常沒有太多空間限制，可以將 code 和 test 放在一起，一起部署
• 商業產品：部署大小可能是問題，可能需要將 test code 分離

Java 的特例#

在 Java 中，一個 package 可以橫跨兩個不同目錄：

source
    com
        orderprocessing
            dailyorders
test
    com
        orderprocessing
            dailyorders

把 production class 放在 source 下的 dailyorders 目錄，test class 放在 test 下的 dailyorders 目錄，它們仍然被視為同一個 package。有些 IDE 甚至能在同一個 view 中顯示兩個目錄的 class。

其他語言的情況#

在許多其他語言和環境中，位置確實有差異。如果你必須在目錄結構間上下導航才能在 code 和 test 之間切換，就像每次工作都要付「導航稅」。人們會因此停止寫測試，工作效率下降。

如果你選擇分離 test 和 production code，確保有充分的理由。很多時候團隊分離只是出於美學考量——覺得 production code 和 test 放在一起「不好看」。但後來發現專案導航變得痛苦。習慣把 test 放在 production code 旁邊，工作一段時間後就會覺得很自然。

替代方案#

可以把 test code 放在同一位置，但用 build script 或設定在部署時移除 test code。只要命名慣例夠好，這完全可行。

總結#

管理 test code 的關鍵在於建立一致的命名慣例和合理的檔案位置策略。好的慣例讓你能快速區分 production code、test class、fake class 和 testing subclass，同時保持導航的便利性。