TDD 单元测试测什么?

前端之家收集整理的这篇文章主要介绍了TDD 单元测试测什么?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

在我们的项目中常常有数据库的身影出没。如何测试数据库相关的内容,就成了一个重要的问题。

传统的 sql 数据库程序与数据库是通过字符串—— sql 语句来交互的。这让组合、重用变得非常困难,因为涉及解析和字符串组合。

对于 Clojure 界新型数据库 Datomic,程序是直接用 Clojure 数据结构来与它交互的:

  • 如果要改变数据,我们会构造一个序列(seq),里面包含一些 map 或者 vector。例如:
[[11344 :player/name "foo"] [13442 :player/sex :sex/male]]
[{:db/id 11344 :player/name "foo" :player/sex :sex/female}]

在这种情况下,我们测试需要保证两个方面的正确性:

程序构造的数据的正确性

我们生成的数据是正确的。例如,一个函数(defn new-player [name sex]) 可能要生成上面的数据。这样的测试是非常容易写的:

(fact "new-player 用玩家名字和性别生成数据库要保存的数据"
   (new-player "foo" male) => [{:player/name "foo" :player/sex :sex/female}])

可以看到,这个测试的目的非常清楚,也非常容易测:它根本就没有连数据库呢。写这种测试可以说是轻松愉快。

生成的数据是能够与数据库正常交互的

可是上面的目标数据是否能够正常地保存进数据库呢?我们常常遇到不能正确保存的情况,比如格式不符合,或者数据类型错。程序员们对此不放心,往往希望连接真正的数据库来测试它。即使在 clojure 的 midje 测试框架下,来测试这个也非常不容易,我们一般需要:

  1. 建立一个内置数据库。创建所有结构和基础数据。
  2. 在测试中建立一个 fixture,正确地在每个用例前新建数据库,在每个测试后清理数据库
  3. 测试用例中把数据写进数据库,然后尝试把它读回来。

这些当然会大大提高测试的写作难度,也严重降低了测试的性能。可是,更重要的是:这样的测试是在测试我们的代码吗?还是在测试我们的数据库知识?

结论

至少在单元测试中应避免第二种测试。实际上,在 REPL 下面手工运行下看看数据是否能够与数据库交互就已经足够!

单元测试是白盒测试,是针对我们所写代码的正确性的测试。在 TDD 下,单元测试的写作过程更加是我们的设计过程。正因为第一种方式更容易写和测试,它鼓励了我们写作纯数据生成函数们,因此可以避免第二种做法下复杂的工作。而第二种工作实际上已经是集成测试了。它当然有自己的用处,但绝对不是我们希望在开发阶段不断重复的工作。

猜你在找的设计模式相关文章