在昨天的練習裡，我們在自己的本機上完成了一個 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 的進階功能，敬請期待！