DApp：开发一条龙 测试一条虫？

2017年，这一年有点特别，许多先进的技术和新的概念集中在这一年迸发。小程序火了、新零售火了、区块链火了、人工智能火了、物联网也火了。

它们有的是首次面世，也有的是早已默默发展了很久，等待一个契机走向大众。

而这当中出现过一个让人印象深刻的小插曲：

这个回答曾经在网络上红极一时，在开怀大笑的同时也不禁发人深思：新的技术若无法落到具体的应用场景解决问题，终究还是纸上谈兵。

区块链技术更是如此。虽说目前区块链的一些技术瓶颈还有待突破，但开发者们应该积极去探索、多尝试，尤其是在应用方面。其中开发DApp就是一个很好的选择。

不得不提的是，在开发DApp时，大部分开发者都会把重心放在开发的过程中，但实际上，还有同样值得开发者们注意的重要一环：测试。

接下来，我们就以抽奖合约为例，从抽奖合约的整个测试流程代码来讲解如何对合约与接口进行测试。

做好准备，又要开始我们的干货时间了。

测试准备

首先我们来看一下项目中，test 目录中文件结构，lib 目录中存放了方便测试调用的封装函数，以 base 命名，而 test 根目录的 cctime 文件包含了主要的测试用例。
编写测试用例之前，我们先熟悉一下 base 文件中的函数，这些函数作为测试工具提供给测试用例调用，封装了合约和访问接口代码。
1、初始化函数编写测试用例之前，需要将常用的方法抽离封装，放入base 文件中，这里我们使用了 supertest 和 chai 作为主要的测试框架，大家可以在源码文件中找到测试文件中的声明。以下是初始化相关的函数：

我们看 init 方法中，对 DApp 的 id 进行了查询，根据应用的名称从主链动态获取当前侧链应用的 ID ，为后续测试接口的调用初始化 DappId 数据。
接下来我们看一下测试常用的工具函数。
2、区块等待在发起一笔交易之后，需要等待交易确认之后再执行下一步的操作，调用 sleep函数进行等待，之后继续执行。这个函数在测试流程中会多次使用，因为 10 秒一个区块的特性，很多的操作需要在区块确认之后获得验证，不仅是写操作，读取的接口依然需要在上一次写操作之后等待区块确认才能获取到最新数据。区块等待相关函数如下所示：

3、账户生成与转账生成随机账户与转账接口也需要测试，我们留意到了在 base 文件头部定义了创世账户的地址和秘钥，创世账户可以通过 asch-js 中的合约接口向新生成的账户转账，随机账户有了余额就能够继续调用应用中的自定义合约，进行合约相关的功能测试。账户及转账相关的函数如下：

a. 随机账户randomSecret 调用 randomSecret 生成随机字符串作为账户秘钥，我们可以看到AschJS.crypto.getKeys 函数能够将字符串格式的秘钥通过非对称加密得出一个包含公钥和私钥的秘钥对，AschJS.crypto.getAddress 通过公钥算出账户的地址。
randomSecret 返回的是一个随机生成但被截取之后的字符串。通常情况下，Asch 只支持符合 BIP39 规范的密钥字符，也就是我们熟悉的“助记词”格式的密码，但这里为了测试方便，直接使用随机的七位字符串，同样可以算出符合规则的公钥，也能计算出地址。当然，随机账户也支持通过指定助记词的方式获取公钥与地址。
b. 转账转账在 DApp 以类型 2 的合约实现，所以这里的转账就是在调用 DApp 内部的合约，我们可以在 giveMoney 函数中看到合约调用的格式。
合约参数结构如下：

• secret为合约调用者的秘钥，String 类型。

• fee为合约调用手续费，bigNumber类型。

• type为合约类型，Number 类型，与自定义合约数据对应。

• args为合约参数，Array类型。

注意：

我们看到 giveMoney 调用合约时请求了 /transactions/unsigned 接口，这个接口可以接受未签名的参数和密钥执行合约，这样做在测试环境虽然没有问题，但是在正式的生产环境中会有很大的风险，我们的私钥内容会有被网络劫持的风险，所以在调用合约时，尽可能避免通过网络传输自己的密钥，而是用本地签名的方式加密参数，然后请求 /transactions/signed ，这点一定要十分注意。

上面的代码通过接收签名参数调用合约的接口，这个函数发送了命名为 transaction 的参数，trs 是用 asch-js 前端 JavaScript 工具库进行签名返回的 transaction 对象。我们来看一个例子：

使用 AschJS.dapp.createInnerTransaction 将合约参数通过秘钥 secret 签名之后传入 submitInnerTransaction 函数，完成合约调用。与上面 giveMoney 函数不同的是，createInnerTransaction 返回的是通过秘钥签名的内容，将签名后的数据通过网络发送，这样提高了整个传输过程秘钥的安全性。
我们来看签名后的 transaction 参数是什么样子：

与上面未签名调用转账接口的参数对比，本地签名后得出的参数中少了 secret 属性，多了 signature 属性，而这个属性把通过 sha256 算法得出的私钥与整个 transaction 参数经过哈希计算之后得出，用于后端接口对参数验证。
其他的合约调用基本上都按照发布文章合约的结构组织参数，完成合约调用的封装。这样，我们就可以着手编写测试了。
合约流程测试

我们现在开始以一个发布文章、用户打赏、结算抽奖和用户领奖整个应用的核心流程进行测试，相关代码如下：

首先，在测试用例 before 函数中初始化测试变量、DApp 数据和创始账户信息作为后续测试函数的基础，然后执行获取频道列表的测试用例。我们使用 await base.dappApiGetAsync('/channels') 请求一个 API，获取到频道列表信息，并用断言库校验结果。
下面我们对核心的业务流程进行测试，测试的思路如下：1）创建频道。2）初始化账户。3）在频道里创建包含抽奖模式的文章。4）模拟三个用户各打赏两笔。5）文章结算。6）获奖用户领奖。7）检查各自账户的余额。
核心业务流程的代码如下：

上面的代码使用受托人创建了一个新频道，并通过频道查询接口通过交易 ID 获取到了频道的 ID，完成了基本的测试逻辑，同时保存了 channelId 作为后续创建文章的数据。

注意：await base.onNewBlockAsync() 是在等待区块确认之后再继续执行。我们看到最初先给账户转入 10500 的 Token，用于创建频道和更新频道的消耗。

打赏文章测试代码如下：

在上面代码中，首先进行账户的初始化，生成了四个账户，一个账户负责创建文章和结算奖励，另外三个作为打赏用户。然后对创建的文章执行两次打赏，为了验证方便，新创建的账户两次打赏的总额为5个Token，创建文章的账户拥有 0.2 个Token，操作之后扣掉手续费保证在结算之前账户余额都是零，方便验证。
另外，我们为了测试需要，将后端关于区块高度的限制暂时去掉，并设置结算区块高度为当前的高度加 2，这样，在用户投票之后直接执行结算。
提示：测试代码中，创建频道或文章之后，因为需要区块确认，所以我们没有办法立即获取到数据的 ID，只能先拿到 transactionId，待区块打包之后，再通过查询接口用 tid 获取实际的数据 ID，再进行下一步的操作，测试文件中，会出现很多这样的处理，这也是区块特性所决定的。
用户打赏测试代码如下：

上面代码中，用另外三个账户对文章进行了打赏，每个账户打赏两次不同的金额，但总额是 5 XCT，所以最终文章的抽奖池中，应该是 15 个 XCT，结算结果根据 15 XCT 的总额进行验证，然后验证文章投票额与投票者的余额是否正确，代码如下：

合约中对抽奖模式的结算规则是受托人 10%，作者 30%，获奖者60%，因为受托人的奖励是平均分给三个账户，所以验证不是那么方便，不过我们只要验证作者和获奖者的奖励额就能确定结算是否正确，那么最终的结果是作者获得 4.5 个 XCT，抽奖人获得 9 个 XCT。
验证奖励测试代码如下：

最终，在根目录执行 npm test ，等测试运行结束，就能看到应用测试执行的结果了。

总结

上述提及的测试代码也只是完成了核心功能验证，并没有完全覆盖到每一个合约和操作场景，如果读者感兴趣可以尝试在此基础上补充或重构，也欢迎对项目提出改进建议。