用 Exposed 框架進行資料庫操作的基礎，在前面幾天已經基本說明完畢了。如果將前面幾天的內容看熟的話，要滿足資料庫互動的需求已經沒有大問題。

後面我們來談談除了單純使用 Exposed 框架之外，一些和其他框架組合，來更進一步操作資料庫的觀念和做法。

首先，我們來談談程式撰寫完畢之後，怎麼做自動測試

什麼是自動測試

之前我們在測試 Exposed 框架時，總是用 println() 函數印出資料內容，來驗證我們是否成功的取得資料。

這種手動測試方式，在專案功能不多，以及專案生命週期不長的時候，或許是沒有什麼問題的。

我們可以在程式更動後，手動檢驗過所有的功能，以確認專案的正確性。並且，由於專案的時間沒有很長，我們可能不會太擔心大家忘記這個專案的功能有哪些，該測試哪些項目。

不過，隨著專案的時間變長，專案的功能變多之後，每次修改都要手動測試所有功能，可能就變得不切實際了。手動測試的過程中可能會遇到以下幾個問題：

• 要測試的功能太多，忘記測試某項功能，並且該功能剛好被改壞。
• 要測試的功能完成的時間太過久遠，大家已經忘記這個功能正確的邏輯是什麼。
• 測試流程操作不正確，導致被改壞的功能沒有出錯
• 隨著功能增加，測試時間花費越來越多

上面所說的這些問題，很多時候是手動測試的特性導致的，因為畢竟測試的操作者是人，只要是人就會有出錯或者動作慢的可能。

如果將部分的測試內容，改成撰寫一段程式來測試寫好的功能，這些問題會得到一定幅度的改善。

• 已經寫好的測試程式，只要不被刪掉，是不會忘記被執行的。
• 無論功能完成的時間多久遠，只要測試程式存在，就不會忘記這段程式當初測試的方式是什麼
• 如果測試程式不被更動，無論執行幾次，每次的測試流程都會是一樣的
• 同樣的測試動作，以程式來模擬幾乎一定比人手動要更快速

所以，將測試的內容從手動操作的測試，改到以程式操作的測試，雖然需要一些撰寫技術，但是如果專案功能變多，以及專案的生命週期夠長，長遠來看是會帶來不少好處的。

撰寫自動測試

我們來實際試驗看看，撰寫一段簡單的自動測試，大概是怎樣的感覺。

我們的 main.kt 裡面，加上一個函數 add()

fun add(a: Int, b: Int): Int{  
    return a + b  
}

這個函數我們預期進行一個測試：測試看 2+2 應該要等於 4，也就是 add(2, 2) 應該要等於 4。

我們在 tests/kotlin/ 資料夾內，建立一個 AddKtTest.kt 檔案，來測試這個函數。

建立完之後，我們在 AddKtTest.kt 裡面撰寫以下內容

import org.junit.Test
import kotlin.test.*  
  
internal class AddKtTest {  
    @Test  
 	fun `測試 add() 2+2 應該是 4`() {  
        assertEquals(expected = 4, actual = add(2, 2))
    }  
}

這邊我們宣告了 測試 add() 2+2 應該是 4() 這個函數，並且斷言（assert）了 add(2+2) 的實際（actual）結果，會等於我們預期（expected）的 4

這時候我們可以點擊左邊的綠色三角，執行測試。一切順利的話，我們就會看到測試成功通過，並且綠色三角前面加上了一個含勾的綠色圓圈，表示這段測試通過了。

如果有人不小心將 add() 的邏輯改錯了，變成

fun add(a: Int, b: Int): Int{  
    return a - b  
}

這時候我們再次執行測試，就會發現測試無法通過，並顯示錯誤內容

expected:<4> but was:<0>
Expected :4
Actual   :0

另外，在網頁版本的錯誤提示內，會顯示出哪個測試函數出錯

-   AddKtTest.測試 add() 2+2 應該是 4

利用這些錯誤資訊，我們就可以很快地找出功能哪邊出錯了，並且針對這些錯誤進行改正。

這邊目前先簡單的介紹了自動測試的撰寫方式。下次我們會實際的利用自動測試的方式，來對 Exposed 框架所寫好的資料庫操作邏輯進行測試。