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

传统的 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 下，单元测试的写作过程更加是我们的设计过程。正因为第一种方式更容易写和测试，它鼓励了我们写作纯数据生成的函数们，因此可以避免第二种做法下复杂的工作。而第二种工作实际上已经是集成测试了。它当然有自己的用处，但绝对不是我们希望在开发阶段不断重复的工作。