iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 14
0
Software Development

邁向專業軟體工程師必修的英文課系列 第 14

Day 14 - [動詞二] 測試

這幾年愈來愈多團隊重視測試,也慢慢有些團隊能接受開發人員同時撰寫測試程式了。當系統和測試開始成對出現時,測試的命名原則也跟著加到團隊的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();
  1. 把測試的行為寫在方法上
    測試案例的名稱可以用描述行為的方法來命名,就是把測試要「做什麼」放在名稱上。這樣的寫法很貼近使用者的行為,在測試裡就會把預期的結果寫在裡面。這個寫法符合測試案例的設計,看不出來預期的結果是這種方法的缺點。
    public void DepositRoomRental_With_Nonexistent_Room_Id();
  1. 把測試行為的預期結果寫在方法上
    這個寫法很像User Story,就是把預期結果跟條件放在名稱裡,這個寫法很口語,可以看出來測試案例的設計目的以及結果。這個寫法的缺點是沒辦法和測試案例的設計直接對應,以及名字變得很長。
    public void DepositRoomRental_Should_Return_Unsuccessful_Message_When_RoomId_Not_Exists();
  1. 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
第一條件句


上一篇
Day 13 - [動詞一] 方法命名
下一篇
Day 15 - [動詞三] Exception Handling
系列文
邁向專業軟體工程師必修的英文課30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言