[Day 15] println() 测试不好吗？来谈谈什麽是自动测试？

用 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 框架所写好的资料库操作逻辑进行测试。