iT邦幫忙

2021 iThome 鐵人賽

DAY 12
1
DevOps

DevOps 萌新的 TeamCity 極速上手寶典系列 第 12

第十二天:在 TeamCity 上執行測試

在昨天的練習裡,我們在自己的本機上完成了一個 ShoppingCart 的類別。因為是用 TDD 的開發流程,所以測試也一併寫好了。不過,雖然我們在自己的電腦上編譯沒問題,但不確定在別人的電腦上是不是也一樣能通過?另外,在團隊開發時,雖然每個人都完成了自己手上的那份工作,但卻沒人能保證將所有人的程式碼合併在一起時還是能通過編譯。

這時就是使用 TeamCity 這種 CI 主機的最佳時機。也就是說,我們把 TeamCity 當成一個中立的第三方,由它來自動測試程式碼是否能在一個乾淨的環境中跑起來,也可以讓它在不同的平台上測試是否一樣能編譯。當我們在 Git 上把所有人的程式碼 Merge 在一起時,TeamCity 也能把所有測試都再跑一遍,確保沒有任何變更把程式碼庫搞爛。

今天我們就來看一下昨天寫好的程式碼是否能通過 TeamCity 的測試。

讓 TeamCity 自動抓取最新變更

昨天在寫程式碼的時候,我用了 2 個 Commit 完成 TDD 的開發流程,一個 Commit 用來增加 Kotest 框架的相依設定、一個 Commit 用來寫測試及核心邏輯。完成後我們把這 2 個變更推上 GitHub,在 IntelliJ IDEA 裡你可以按一下右上角的 Push 換鈕,在彈出視窗裡確定要推到的 Remote Branch 及 Commit 後按 Push 即可。

TeamCity 預設自動抓取最新變更的行為是每 1 分鐘會自動 Fetch 一次 Repository,若是有任何變更的話就會自動 Pull 回來然後跑 Build(假如您不喜歡這種 Long-Polling 的作法,也可以另外設定在 Webhook 的方式),所以當我們 Push 完一分鐘後,就可以到 TeamCity Server 上看一下它是不是有自動啟動?

從畫面上您可以看到 TeamCity 真的有自動抓到最新變更,Build 也成功的完成了。TeamCity 會自動幫每一個 Build 紀錄以自動遞增的數值來編號,也會列出這個 Build 是由哪個 Branch、由哪個作者發動以及測試有沒有通過。

瀏覽建置詳細紀錄

點一下畫面上的 Build 編號,可以進入到該次 Build 的詳細畫面。在這個畫面上您可以看到有執行哪些測試以及是否通過?以及這次的 Build 跟哪幾個 Commit 有關。

點一下 1 test passed 的連結進入測試紀錄詳細畫面。我們可以看到 TeamCity 會列出我們寫在 Kotest 裡的測試名稱及結果。

等一下?TeamCity 說測試通過了?我們什麼都還沒設定啊?

是的,因為在設定專案的時候,TeamCity 已經抓到 Gradle Build Script 並自動幫我們設定好 Build Step 會執行 $ gradle clean$ gradle build 兩個指令,而其中 $ gradle build 又相依於 $ gradle test,所以測試這個動作就被自動包括在整個 Build 的動作裡了。而您看到的各種測試紀錄畫面是因為 TeamCity 內建就支援 JUnit 系列的輸出,所以無需額外設定就通通都搞定了!很方便吧!

測試失敗的話會怎麼樣?

目前我們走的幾乎就是 Happy Path,反而缺少了點真實感。所以接下來我們增加一個新的測試案例,故意讓 TDD 的流程沒走完,來看一下 TeamCity 上會有什麼反應吧!

回到 IntelliJ IDEA,我們在 ShoppingCartTest 增加一個新功能的測試,讓 ShoppingCart 可以回傳購物車裡的物件數量:

class ShoppingCartTest : FunSpec({

  context("一個購物車") {
    // ...

    test("當加了 2 個商品後會回到商品數量為 2") {
      // Arrange
      val product1 = Product(id = 1, name = "Product 1", price = 100)
      val product2 = Product(id = 1, name = "Product 1", price = 100)
      val shoppingCart = ShoppingCart()

      // Act
      shoppingCart.add(product1)
      shoppingCart.add(product2)

      // Assert
      shoppingCart.count() shouldBe 200
    }
  }

})

雖然 IntelliJ IDEA 已經標記找不到 count() 方法,但我們不管就直接 Commit(IntelliJ IDEA 又會再擋一次也不管就 Commit Anyway)並推上 GitHub 然後讓 TeamCity 跑跑看結果。

從畫面上看到紅驚嘆號就知道 Build 失敗了,TeamCity 果然很盡責!

點 Build 編號進去看一下詳細資訊,就會看到 TeamCity 說有 2 個問題,主要的原因就是 Compilation error。把 Log 展開,就會看到當時的 Build Log 出錯的那一段摘要。

小結

從今天在 IDE 及 TeamCity 之間切來切去,就可以瞭解 CI 主機是如何在背景自動的協助開發者驗證測試碼,確保程式碼庫裡的品質。讀者也可以利用這個機會練習一下看怎麼完成 count() 方法的實作,除了在 IntelliJ IDEA 裡確認通過測試外,也別忘了在 TeamCity 再驗證一次喔!

接下來的練習也會是類似這樣的流程:在 IDE 裡增加品質工具、寫程式增加新功能、送到 TeamCity 確認程式碼品質。也會在這個過程中體驗更多 TeamCity 的進階功能,敬請期待!


上一篇
第十一天:用 TDD 實作購物車類別
下一篇
第十三天:用 ktlint 做程式碼風格檢查
系列文
DevOps 萌新的 TeamCity 極速上手寶典31

尚未有邦友留言

立即登入留言