第十二天：在 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 的进阶功能，敬请期待！