這幾年愈來愈多團隊重視測試，也慢慢有些團隊能接受開發人員同時撰寫測試程式了。當系統和測試開始成對出現時，測試的命名原則也跟著加到團隊的Coding Convention了嗎？
或許寫測試的方法跟寫一般方法的做法差不多，但其實測試要溝通的東西更多，所以有一些眉角或許可以使用看看。

檔名

測試檔的檔名應該和測試的標的物對齊，換句話說，如果待測試的類別名稱為：
** HotelCalifornia/Service/RoomReservation.cpp**
那測試檔的檔名應該是
** HotelCalifornia/Service.UnitTests/RoomReservationTests.cpp **
請注意檔名及目錄名，還有記得加s(因為會有多個測試案例放在同一個檔案裡）。
因為測試的種類很多：單元測試，整合測試，壓力測試，功能測試...等等，所以在目錄名稱上就要標注他的測試種類。當然，如果要放在檔名也是可以的，端看團隊的共識。

命名原則

因為測試的命名通常都非常的長：下一段會看到。所以測試的命名通常都會用Snake_Case的方法命名，例如

    public void GetRoom_Should_Return_Available_Room_Information();

測試內容

以下的測試我們都以單元測試為主，其他測試都適用。
測試方法的命名有很多種做法，這可以看團隊喜歡的方式，各有各的優點。為了方便說明，假設有一個測試案例，要呼叫方法DepositRoomRental(Tenant tenant, int roomId)，假設RoomId不存在要回傳失敗訊息。
那為了寫這個測試，有以下的方法可以使用:

1. 把測試案例寫在方法上
   這種方法很直觀，就是直接表明這個測試是要測什麼，沒有太多的資訊在測試案例上，如果不希望看到太長的命名，可以使用這個方法。它的缺點就是沒有太多的資訊，而且一但要寫更多的測試案例，就要另外再想其他的名稱。不太建議使用這個方法。

    public void Test_DepositRoomRental();

2. 把測試的行為寫在方法上
   測試案例的名稱可以用描述行為的方法來命名，就是把測試要「做什麼」放在名稱上。這樣的寫法很貼近使用者的行為，在測試裡就會把預期的結果寫在裡面。這個寫法符合測試案例的設計，看不出來預期的結果是這種方法的缺點。

    public void DepositRoomRental_With_Nonexistent_Room_Id();

3. 把測試行為的預期結果寫在方法上
   這個寫法很像User Story，就是把預期結果跟條件放在名稱裡，這個寫法很口語，可以看出來測試案例的設計目的以及結果。這個寫法的缺點是沒辦法和測試案例的設計直接對應，以及名字變得很長。

    public void DepositRoomRental_Should_Return_Unsuccessful_Message_When_RoomId_Not_Exists();

4. BDD格式
   把程式條件、呼叫的方法及預期結果放在一起，BDD在某些測試案例(或者團隊有使用BDD做測試時)時可以很清楚的描述測試案例的因果關係，但它的寫法需要特別學習一下。
   如果用User story的語法來寫也可以的。

    public void Given_Nonexists_RoomID_When_DepositRoomRental_Then_Will_Return_Fail_Message();

總結一下就是：寫測試案例時，至少要具備以下的資訊：

• 測試的目的
• 測試的標的是那個方法
• 輸入的資料或者狀態
• 預期的結果

假設語氣及未來式

到今天第十四天，終於有一個比較像英文課的地方了。
原則上，測試案例發生的都是假設條件，在符合條件或不符合條件下會發生某些預期的結果，因此命名的句型會用假設語氣，只是寫法上會把If省略掉。
但寫法上就是條件句而己，所以會用假設語氣的第一條件句：現在簡單式表示將來有可能實現的假設
If + 簡單現在式, S will ~ (單一事件)
這樣就不難理解為什麼BDD會用Will了
但如果用像AssertJ, FluentAssertions,jsassert 這種工具，Should還是在第一條件句下，用來描述因果關係，例如

If it continues to rain this hard for another hour, it should start flooding.

所以在寫測試案例時，記得使用假設語氣來命名測試方法。

你的團隊也有寫測試嗎？怎麼命名的呢？分享一下你的團隊的測試命名原則吧！
參考資料:
7 Popular Unit Test Naming Conventions
第一條件句