项目首页：https://github.com/Kujiale-Mobile/kooltest
项目文档：https://github.com/Kujiale-Mobile/KoolTest/wiki

不管是需求文档、代码、还是测试用例，本质上都是一种知识的表达，不同时期每一种知识载体的权威性也不同。比如在需求评审阶段，需求文档就是最权威的知识。而测试阶段，测试用例又变成了最权威的知识载体。当代码上线后，则代码就成了最权威的知识载体（无线上 Bug 情况下）。如果每一步都做的很完美，那么这三个载体承载的知识点是一样的，只是表达的方式不同，但他们都具有权威性。但在现实中，我们是不可能做到如此完美的。很多公司的情况是，随着不断的迭代，需求文档和测试用例因为更新不及时，基本没有太大参考价值，线上代码成为了唯一的权威知识载体。随着研发人员的变动和项目的变大，最终导致没有任何一个人可以全盘知道这个系统的所有细节，代码上线也变得心惊胆战，而这导致了无法稳定的可持续性交付。

那我们要如何去解决这类问题呢？很自然想到的一个是，我们可以建一个文档，这个文档要尽可能和线上的权威知识源保持一致，在上线前投入人力按照文档上的说明逐条执行，如果出现问题就和开发沟通，去识别到底是产品需求的变化还是产生了 BUG。另一个可能想到的是我们要上自动化，我们再写一堆测试代码去描述业务，然后自动化执行发现业务问题。 这两种方法本质都是想在除了代码作为唯一权威知识源的情况下，去构建另外一个冗余的权威知识源。而这两种各自都有其缺点，第一种需要大量的人力资源投入做到文档的更新和执行上，往往很容易漏测。第二点产生的冗余知识代码书写和维护本身也是一个大难题，最终也只局限在少部分人中，最终一样不断人来人走，变得无人能懂。

那我们思考，可否把这些冗余的知识源既可以用领域语言的表达出来，而且还可以执行呢？目前行业中 DDD 和 BDD 的思想给我们提供了一些思路，KoolTest 框架即是该思想理念的集合。