比特币:DApp：开发一条龙 测试一条虫？_btc钱包最新下载网址

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

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

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

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

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

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

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

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

DappRadar研究人员：Arbitrum空投对DeFi表现出兴趣:金色财经报道，DappRadar 的研究主管 Pedro Herrera 表示，传统市场的银行业紧张局势以及监管机构对中心化交易所的打击可能会促使用户转向去中心化金融应用程序。如果你开始看到 DeFi 的这些用例如何开始适应并赋予你更多的自主权来基本管理自己的资产和投资，这就是 DeFi 被高度使用的原因。像 Arbitrum 这样的项目正在他们的社区中创造一种忠诚度和参与感，这反过来又可以“吸引开发人员构建更好的产品，并最终吸引更多用户参与该项目。

DappRadar 的一份新报告发现，第一季度 DeFi 锁定的总价值从去年第四季度的 600 亿美元增长了 37% 至 833 亿美元。[2023/4/4 13:43:11]

测试准备

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

加密猫研发团队Dapper Labs与Dr. Seuss Enterprises达成合作:7月21日，基于以太坊的区块链游戏“CryptoKitties（加密猫）”的研发团队Dapper Labs宣布与Dr. Seuss Enterprises达成合作，将推出描绘该公司最具标志性角色的代币化数字收藏品，包括Dr. Seuss最受欢迎的角色，如Cat in The Hat、The Lorax和Thing One and Thing Two。（Cointelegraph）[2020/7/22]

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

动态 | LiquidApps推出新服务LiquidLink 可实现Etherneum与EOS的跨链互操作:据MEET.ONE 7月27日消息，LiquidApps今日发推介绍了DAPP 网络创建的新服务LiquidLink，其可实现Etherneum与EOS的跨链互操作，并发布了演示视频。[2019/7/27]

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

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

动态 | 5月EOS、ETH DAPP单笔平均交易额环比上月均呈下降趋势:据RatingDapp和RatingToken大数据监测显示，5月份EOS/ETH/TRON三大主流公链平台Dapps交易笔数分别为：EOS(111946597)>TRON(29909346)>ETH(2272894)；交易额分别为：EOS(107,642,177.5EOS)，ETH(1,279,580.5ETH)，TRON(15,174,007,588.6TRX)。从单笔平均交易额来看，5月份EOS Dapp 单笔平均交易额为0.96EOS，环比4月下降3.28%；ETH Dapp单笔平均交易额为0.563ETH，环比4月下降11.63%；TRON Dapp单笔平均交易额为507.33，环比4月上升31.66%。[2019/6/11]

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

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

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

动态 | 以太坊及EOS每月新开发DAPP数量创新高:据bitcoinexchangeguide报道，根据StateOfTheDApps.com的数据，尽管使用率较低，目前在以太坊和EOS智能合约平台上每月开发的新DAPP数量达到了历史最高水平，每月新发布近180种产品。以太坊仍然是DAPP开发最受欢迎的平台 ，每月共有105个新项目在其上推出。然而，以太坊网络目前每月仅有141300名客户使用。[2019/1/9]

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

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

注意：awaitbase.onNewBlockAsync()是在等待区块确认之后再继续执行。我们看到最初先给账户转入10500的Token，用于创建频道和更新频道的消耗。打赏文章测试代码如下：

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

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

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

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

总结

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

标签：EOSBTC比特币APPDEOSbtc钱包最新下载网址泰达币和比特币区别在哪里Wrapped Bitcoin Diamond

TRX热门资讯