This section reviews the state-of-the-art in IoT and blockchain integration, focusing on testing. Prior work has shown that IoT and blockchain can be integrated, allowing peers to interact in a trustless, auditable manner via the use of blockchain as a resilient, decentralized, and peer-to-peer ledger. Work has also been done on the topics of security and privacy of IoT and Blockchain integrations . Beyond that, work has focused on formal verification of smart contracts , and how to write smart contracts “defensively” to avoid exceptions when multiple contracts interact. The current state-of-the-art with respect to testing, however, is lacking because blockchains are infrequently tested at scale in a systematic and repeatable manner, so we focus on that below.
6.4.1. Functional vs Model-Based Declarations
Currently, as far as we can tell, PlaTIBART is the only modelbased system for deploying Blockchain test networks,with Ethereum or otherwise. There are some tools, such as Nixos, 1 that provide for repeatable installation of their Linux distribution and therefore via use of the NixOps devops tool, can declaratively define deployments of private Ethereum networks. However, this still requires functional declaration of the instances to be created. The benefits of a model-based approach are that it allows much easier variation in the outputs, additionally, a modelbased declaration can be modified to create the functional declaration inputs of other systems easily, thereby maintaining easy adaptability while also increasing interoperability with other tools, toolchains, and workflows.
Testing on Live Environments, Non-Repeatable
Blockchain systems, particularly Ethereum, focused extensively at the start on testing your smart contract code on a public, global, and nonmodifiable instance of the Ethereum network they call the Test Network. Ethereum has at least added support for smart contract unit testing, testing smart contracts in an emulator, and calling that integration testing. However, these approaches lack robustness and repeatability.
The use of a public non-blockchain, even a testing one, for development poses several potential issues for developers. Firstly, the chance of publishing content to the blockchain that is intended to be secret is a high concern in a test environment. Secondly, reliance upon a public blockchain for testing removes the ability to control the frequency, latency, and predictability, or lack thereof, of your testing environment. This is important due to the common need for tests to be faster than realtime execution speed.
The use of an emulator to do integration testing of only the smart contract component of the system lacks robustness because of several reasons. First, it doesn’t use the same client as production code would. Second, it ignores the need to include the client itself in the integration testing process. Third, it focuses on the HTML/JavaScript interface of the official client, while ignoring the other interfaces that geth provides, such as the JSON RPC API.
Therefore, we believe Ethereum has issues with the design philosophy of their testing mechanisms. Additionally, we have noted previously that Ethereum’s documentation was incomplete and spread across multiple pages for the same APIs, and as of the date of this publication the issue still exists.
6.4.3. Lack of Defined Integration/Testing Methodologies
Unfortunately, there is currently a severe lack of support for testing Blockchain systems and software when not using the precise scenarios envisioned by the Blockchain system’s creators. For instance, Ethereum doesn’t have any tools, testing or otherwise, that assist in integrating the official command line client of Ethereum: geth into applications. There is an official IDE, the Remix Solidity IDE, which enables unit testing but no support for integration testing at all currently. Their focus is on unit testing their smart contracts and “integration testing” their contracts inside a separate simulator, and not the geth client and private test networks. Other Blockchain and/or Distributed Ledger technologies, such as Hyperledger Fabric, at least have unit testing support and support integration testing, but at the time of writing, they have zero documentation on it.
[ad_2]
This article has been published from the source link without modifications to the text. Only the headline has been changed.
