编写单元测试的原因

让我们暂时设想一个场景。假设Pat刚刚完成了一项小型功能改动，向系统中添加了几十行代码。他们对这次修改相当有信心，但已经有一段时间没有在部署后的系统中实际测试过了。Pat运行了构建脚本，该脚本将更改打包并部署到本地服务器。他们打开浏览器，进入应用的相应页面，输入一些数据，点击提交……结果出现了堆栈跟踪！

场景：手动测试与单元测试

现在我们来通过一个具体场景思考一下单元测试的应用。

Alex倾向于使用单元测试，并希望尽可能轻松地完成项目。每当编写一小段代码时，他们都会添加一个单元测试，以验证所做改动是否正确。随后，他们会运行所有单元测试，整个过程仅需几秒钟。这样，他们无需长时间等待就能知道是否可以继续下一步。

如果发现问题，Alex会立即停止并修复。由于每次只添加少量代码，问题更容易被发现，而不是在累积大量新代码后才发现错误。

Alex会永久保留这些测试用例，与系统其他部分一同保存。每当自己或他人修改同一区域的代码时，这些测试都能持续发挥作用。这些单元测试支持回归测试，使Alex不再需要花费数分钟去确认新改动是否破坏了原有功能。

此外，Alex的测试还为团队节省了大量时间，帮助大家快速理解系统行为。当团队成员询问系统如何处理X和Y的组合时，使用手动测试的开发者可能会回答：“我不清楚，让我去看看代码。”他们可能在一两分钟后给出答案，但常常需要花费更长时间查找。而使用单元测试的人只需查看对应的单元测试，就能立刻得到答案。

让我们跟随Alex的脚步，开始学习如何编写简洁、聚焦的单元测试。首先，我们要确保掌握基本的JUnit概念。