Testing Automation is Different for Blockchain Applications
While working at SimplyVital Health for the past 6 months, I have gained a large amount of experience with blockchain and blockchain adjacent technologies and wanted to make the information I learned available to others. As such, this article is intended for both software developers new to Dapps and interested laywomen and laymen.
- Context and Environment
- The Smart Contract
- The Front End
- Testing Frameworks
- Miscellaneous Considerations
Software testing is vital to any technology-based endeavor. Determining whether a given application is functioning properly is key not only for the application’s immediate functionality, but also for medium- and long-term goals of sustainability, maintainability, and scalability. Automated testing, in particular, can contribute significantly to these goals by providing consistency and depth to test coverage as an application changes and grows over time.
When dealing with Blockchain-based applications (decentralized apps, “Dapps,” as they are known to blockchain programmers), a tester will often need to contend with the asynchronous nature of the blockchain. What does “asynchronous” mean? There are many perspectives on the practical and technical details of “asynchronous” environments (e.g. for Javascript-related material, see Kyle Simpson’s book “Async & Performance”), but suffice to say an “asynchronous” coding environment is one in which the results of functions are returned whenever they are ready vs. returning in the order in which they were placed.
Blockchains function in this manner. Moreover, their asynchronous behavior is subject to the speed of the network they are being run on. Additionally, for a block/transaction (a chunk of code that is run against a regulating “smart contract”) to be processed, the transaction must be validated by a “mining node” on that blockchain. A “mining node” is a computer that adds blocks to the blockchain by spending electricity to run the code of the transaction in order to reap a reward in the form of transaction fees and bounties. A miner (the individual or entity running the mining node) can choose whether or not to validate a block depending on its reward, which adds an additional layer of uncertainty to the blockchain environment. Additionally the block needs to be accepted into the blockchain network via a majority consensus among the population of mining nodes. This lack of consistent speed, while not necessarily problematic in-and-of-itself, adds additional complexity to an already asynchronous environment. For an automated test suite to be consistent, it will need to interface directly with the transactions, often by way to reading transaction receipts and confirmations.
Given these details, the two, concrete environments an automated test suite for a Dapp will need to contend with are 1) the smart contract itself and 2) the front-end and its interactions/responses to activities on the blockchain.
The stakes for testing a Smart Contract are significantly higher than for other aspect of a block-chain-based application. If the logic and functions of a smart contract are poorly, insecurely, or inefficiently built, the resulting problems can quickly compound. Beyond immediate security concerns, each update to a smart contract requires the migration of all prior transactions. If this migration does not occur, prior transactions can be lost and the immutability of the blockchain (one of its primary benefits) can become compromised. Hence blockchains are rarely updated, except when absolutely necessary (e.g. Ethereum’s 2016 DAO breach and the resulting hard fork). Additionally, concise code will increase the chances that your transactions get processed, as it is less expensive for mining nodes to run a smaller contract. It is important to get the contract correct early on, to mitigate these issues.
The Truffle framework is a common tool for smart contract test automation. Truffle tests can be written in Javascript or Solidity and utilize test accounts running against a local instance of the Ethereum blockchain. It is important to note that while Truffle test can certainly provide clear and efficient feedback regarding your smart contract’s behavior, the test environment is also far more stable and simple than the main Ethereum network itself. Nonetheless, the benefits of feedback from this testing environment greatly outweigh potential shortcomings.
The front-end of a blockchain based application may be very similar to the front-end of any other application; there is no specific approach to front-end design that a blockchain based application must have. However, if the front end is meant display any of the actions of the blockchain to its users — e.g. transactions that are sent, pending, or received — those functions will need to be accessed. And if the users themselves are meant to provide, access, and interact with their own wallets and currency, this will need to be accounted for. There are a number of third-party libraries for providing this kind of access to wallets, but for the tester, these can prove difficult to manage, depending on the method(s) of accessing these wallets and their dependencies.
Even if the blockchain is meant to remain fully in the background of an application, if the application’s blockchain-related functions are meant to be tested, simple “async/await” methods might not do the trick. Often it is more reliable and efficient to wait explicitly for the receipt(s) and confirmation(s) of the blockchain’s activities. This type of functionality can be provided by third-party libraries such as Web3 or ethjs.
Similar to Truffle’s Ganache testing environment, several blockchains, including Ethereum, provide public test networks for developers to run against. Some of these test networks on the Ethereum blockchain include Rinkeby, Ropsten, and Kovan. These test networks often offer free, though limited, currency (“ether”, in the case of Ethereum) to utilize during tests. Not only do these test environments drastically lower the cost of running tests on a blockchain, but they provide a more realistic response time, with transactions taking the standard (though still highly variable) response time of 10–30 seconds (https://etherscan.io/chart/blocktime), as opposed to Ganache’s rapid-fire response rate. (Incidentally, SimplyVital Health is currently working on a solution to the immensely variable speed of block propagation, funded by the National Science Foundation: https://www.beckershospitalreview.com/healthcare-information-technology/simplyvital-health-receives-grant-to-study-integrating-blockchains.html)
Depending on the coverage required, there are several different tests that one could implement. “Unit” tests — checking the most basic presentation and features of an application — might be performed using Chai, Mocha, and the test runner, Karma. “Functional” and “End-to-end” tests — checking the full functionality of an application from the first interaction through all details of it’s features — from the user’s perspective might be accomplished by constructing a Page Object Model and utilizing Selenium and Protractor. As mentioned above, Truffle can be used to directly test the logic and functionality of your smart contract (again, a smart contract should be comprehensively tested prior to deployment!). Here is a list of various frameworks:
Front-End Unit Test Frameworks
Front-End End-to-End/Functional Test Frameworks
Smart Contract Test Frameworks
A complete test suite for a Dapp will utilize a combination of frameworks in order to validate the core functionality of both the smart contract and front-end.
Big Numbers — the values of wallet addresses and gas prices don’t always fit in standard javascript variables. “Big Number” libraries hash larger numbers into strings for more manageable variables. Often, these libraries will contain their own math and logic.
Want to test out or implement any of the technologies listed mentioned above? Checkout out SimplyVital Health’s open source, blockchain based web application Nexus.
As of the publishing of this article (January 2020), SimplyVital Health is hiring! We are currently looking for Principle Front-end, Dev-ops, and Security engineers and Healthcare Data Scientists. Please visit the following sites for more information:
https://angel.co/company/simplyvital-health
https://www.simplyvitalhealth.com/
https://www.facebook.com/SimplyVitalHealth/
Please contribute to the discussion in the comments below. Thanks for reading!
Published at Tue, 07 Jan 2020 14:12:55 +0000
{flickr|100|campaign}
