单元测试的困境与突破-优快云博客

本文链接：https://blog.youkuaiyun.com/firefox1/article/details/80670104

“单元测试”，不知道是谁提出来的概念，这么多年来一直困扰着我。我一方面相信它能够确实改善代码的质量而在项目中不断的尝试；另一方面，因为尝试的过程中很少的得到正面反馈又在怀疑它的实用性。

我感觉自己是那只故事中结网的蜘蛛，网还没有结好就被风吹坏了，坏了又开始重新结，年复一年。虽然有过一些思考，但是无从下笔来记录这些年走过的路。

单元测试，说起来简单，“单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。”；做起来难，代码到处都是，要测试的那“一小段”代码在哪里？

这样的定义，可以让任何不懂单元测试的人来做一个单元测试的demo，但最终没有任何作用。为什么，因为我们的项目里有太多的代码，而代码与代码之间的关系复杂，就像让一个人去面对大海，试问每一滴水都需要进行单元测试吗？

我第一次听到单元测试这个概念是在15年前，我加入徐总的团队（现在的诺怀软件）后，这个团队对代码的质量要求很高。

当时参与的是一个胖客户端的WinForm项目，这种项目的特点是直接从数据库中读取数据，然后将其展现到WinForm窗体上，用户在窗体上保存修改的信息后，再将数据写回到数据库中。业务代码几乎都耦合在窗体的事件处理函数中。要加入单元测试，首先要对现有代码进行重构。

重构意味着修改现有的代码，意味着更多的测试工作，考虑到项目的进度，我们把重构放在项目压力小的时候，因此，最后单元测试并没有在项目中真正开展起来。

虽然没有真正展开，但是在经过几次尝试后，我感受到要并不是所有的代码都适合单元测试，随便对一个项目说“我们要通过单元测试来改善项目质量”不现实的。

问题到底在哪里呢？

假设有这样一段需求：“用户将客人订单标签拖到餐桌列表时，首先要检查该时间段内，餐桌是否已被预定。如果已被预定，弹出提示并取消当前操作；如果没有被预定，那么检查该桌子的容量与客人的数量是否匹配。如果不匹配，弹出提示并取消当前操作。最后更新订单数据，并将数据保存到数据库。”

这段C#代码大概会是这样。

private function tableChart_beforeChange (TableChartEvent event) {
  if(this.isTimeRange(event.timeRange))
  {
    MsgBox.show("改时间段已被其它客户实用");
    event.cancel = true;
    return;
  }

  if(this.getTable(event.id).capacity < this.order.capacity)
  {
    MsgBox.show("该桌太小，不能满足订单需求");
    event.cancel = true;
    return;
  }

  this.updateOrder(this.order);
}

上面的代码虽然已经很简化了，但是还是没有逃离与界面和数据库的耦合，面对这样的代码，该怎样进行单元测试呢？

如果把时间向前拨回到15年前，我可能是这样思考的

这个事件包含了一个完整的业务逻辑，因此要用一个测试来保证其完整性。要调用tableChart_beforeChange函数，我得首先创建这个函数所在的类的实例；然后这个类是窗体类，要初始化这个窗体类，得先初始化包括数据库在内的配置；然后，这个数据是业务数据，我得保证数据库中有符合测试要求的业务数据。当我想到这一点时，我崩溃了。对了，不是有mock框架吗，可以mock数据库的访问啊。那我先看看这个窗体类初始化的时候访问了哪些数据，天呐，是直接在代码中通过SqlConnection，通过拼接sql的方式来操作的数据，无法mock，我又崩溃了。

由于碰到了这样或那样的问题，我第一次单元测试应用是失败的，我得出结论是要使用单元测试，就得改变代码的写法。

单元测试要测什么样的代码呢？