Testing Strategies for Enterprise Blockchain Apps

blockchain app testing

This is a guest post by Michael G. Solomon, PhD CISSP PMP CISM.

Interest in blockchain has grown in the last few years across organizations of all types, driven by the technology’s resilient and trusted ability to share information among business partners.

Although blockchain started as a vehicle to bring cryptocurrency into the mainstream, a fairly new approach to blockchain technology is starting to impact many aspects of business: the enterprise blockchain.

Enterprise blockchain implementations are different from the more familiar public blockchains. Scaling up to an enterprise-level places separate demands on the technology, and these new applications require updated approaches to app development and testing to ensure they deliver on their long list of promises.

Let’s explore how enterprise blockchain apps are different from public consumer blockchain apps and how to best approach testing this new class of applications.

Enterprises Place New Demands on Blockchain

Blockchain technology was originally proposed in a 2009 paper by an author (or authors) using the pseudonym Satoshi Nakamoto. Nakamoto proposed a revolutionary approach to implementing a cryptocurrency, Bitcoin, using a trustless distributed ledger. While this new technology was a giant leap forward in distributed and decentralized storage and processing technology, Bitcoin only scratched the surface of what blockchains could really do.

Blockchain implementations quickly matured to support many types of transactions beyond just cryptocurrency exchanges, and it became clear that the first-generation Bitcoin approach to blockchain was too limiting. The Bitcoin implementation didn’t support enough functionality to automatically process complex transactions.

Only four years after Nakamoto’s paper that started the blockchain revolution, Vitalik Buterin proposed a second-generation blockchain implementation, Ethereum. Ethereum integrated smart contracts, which define rules that all nodes on the blockchain network must follow to access blockchain data. Smart contracts took blockchains one step closer to being useful in an enterprise environment.

The only new features that enterprise users needed to start using blockchain technology were methods to handle sensitive data, higher performance, and the ability for blockchain apps to coexist with traditional enterprise applications. This happened in the third generation, the enterprise blockchain.

Several blockchain implementations have since emerged, or have proposed upcoming release dates, to satisfy this need, including Hyperledger Fabric, from The Linux Foundation, and the upcoming Enterprise Ethereum, from the Enterprise Ethereum Alliance. These products address the limitations of previous blockchain implementations and make it possible to incorporate blockchain technology as part of an enterprise IT solution.

Enterprise IT solutions place unique demands on any technology. They must integrate with other IT components with little need for individualized care, carry out their assigned function in a timely fashion for high-frequency activity, and experience minimal downtime. In short, enterprise IT solutions must be available and functional without requiring much human maintenance. Resilience, availability, autonomy and transparency are all goals that you must formally address when testing enterprise blockchain applications.

These requirements may seem to be common application testing goals, but each one poses new obstacles and requires additional focus in an enterprise blockchain environment. Copies of data and code reside in multiple locations. Execution times of smart contracts are not the same at all nodes, while results are required to be the same. Transactions in blockchain environments generally do not play by the same rules as the familiar database application rules. Blockchain data is essentially immutable and stored chronologically.

All of these foundational characteristics in blockchain applications require that testing be approached with more rigor than with traditional applications.

Modern Test Case Management Software for QA and Development Teams

Types of Enterprise Blockchain Application Tests

Testing enterprise blockchain applications isn’t an entirely new discipline; it is just an extension of what you already know. Essentially, every type of test that you’re used to carrying out for more traditional types of applications is still applicable with blockchain applications. When you’re testing an enterprise blockchain application, there are just a few more considerations to address.

You want to ensure that the decentral nature of the application doesn’t negatively impact its operation. A solid testing regimen can do that. Let’s look at some common tests for enterprise blockchain applications.

Functional Tests

A functional test validates that the software operates as intended. This type of test is the most familiar to experienced application testers.

The difference is that enterprise blockchain applications nearly always operate as a part of a larger ecosystem. That means data input and output may not be clean and easy to simulate. It is important to create test cases for as many potential normal and boundary conditions as possible. Blockchain applications generally depend on autonomy and should handle exceptions without requiring human interaction.

Remember that all smart contracts reside on the blockchain. That means smart contract code is essentially immutable, just like blockchain data. Any smart contract code that gets deployed is there to stay, bugs and all. Blockchain application testing is crucial to ensure that you don’t deploy smart contracts with any defects. Those defects are more difficult to rectify than with traditional applications, and any bad data that those defects may have placed on the blockchain can be awkward to handle as well. Testing can help avoid such issues.

Security Tests

One of the characteristics of enterprise blockchain applications is the ability to securely share data among business partners. In a closed blockchain, these partners may all belong to a single organization. In a consortium blockchain, partners may span many organizations. In either case, it is likely that some data on the blockchain should be restricted to authorized users.

Enterprise blockchain implementation provides various access control and encryption features to support limited data access, but these features must be exercised during testing. Tests should include assurance that moving from a centralized access control authority to a decentralized (or partially decentralized) model does not decrease data security guarantees.

Integration Tests

Enterprise blockchain applications commonly operate as information-sharing and integration layers. For example, many supply chain blockchain applications provide the mechanism to track products as they travel from producer to consumer. Each participant consumes data and may add new data to the blockchain, while also maintaining their own IT systems and applications.

Each participant must integrate their IT applications with the blockchain through an application programming interface (API). The API is crucial to enterprise access of blockchain data and functionality, and testing each API function is necessary to ensure smooth and transparent integration with external applications.

Performance Tests

One of the current issues often cited with blockchain technology is its lack of scalable performance. Enterprise blockchain implementations are always improving to address this criticism. First- and second-generation blockchains commonly use consensus mechanisms that limit overall throughput.

The most common consensus mechanism, proof of work (PoW), is extremely resource-intensive and rather slow. PoW works well in completely untrusted environments but isn’t sustainable. Enterprise blockchain implementations generally use newer consensus mechanisms, such as proof of stake (PoS) or proof of activity (PoA). In an enterprise environment, there is generally some level of authentication, so a basic level of trust may exist that eliminates the need for purely computational consensus.

Enterprise applications often have performance and response standards. Your blockchain applications must meet the minimum standards of each traditional application it integrates with. Performance testing helps to determine if your blockchain application meets these standards. If it does not, you may need to explore using a different consensus method, altering smart contracts or even changing the network node configuration. Performance testing can lead to many types of changes to improve the blockchain application.

Peer and Node Tests

Decentralized processing and storage must result in identical copies of the blockchain data across all nodes. That means all smart contract code must be deterministic. In other words, a smart contract must produce the same results on all nodes. If any smart contract comes up with a different result, that copy of the blockchain would be different from other copies.

The trick is ensuring that there are no inputs that are local and potentially different across nodes. That’s where peer and node testing comes in.

Your tests should evaluate how well peer and node differences affect smart contract operation. All smart contract code must be deterministic and should exhibit level performance. Although your performance testing should look at overall blockchain application performance, peer and node testing should compare relative performance of nodes. The earlier you can isolate slow nodes, the better you can improve the overall performance of the blockchain network.

This type of application testing is often part of post-deployment assessment and maintenance in traditional IT environments. However, in the enterprise blockchain, it is an important part of testing before deployment.

Enterprise Blockchain Application Testing Obstacles and Best Practices

Although many areas of testing enterprise blockchain applications are similar to testing traditional software applications, the technology’s unique characteristics result in some obstacles. Testing is somewhat more difficult due to a few blockchain nuances.

Although smart contracts may have rich functionality, most of the operation is silent. Blockchains are generally implemented as automated data processing and persistent store components. They exist to silently handle data with little or no human interaction. That makes testing a bit more challenging. The autonomy of blockchain means you must design test cases carefully and execute them to cover as wide a range of scenarios as possible.

Another nuance of testing blockchain applications is the fact that all data, including test data, is persistent. You can’t set up a test suite, carry out tests and then delete the test data. The data store, the blockchain itself, is an integral part of the application. With traditional applications there is a more clearly defined separation between the software and the database. While it is possible in an enterprise blockchain environment to “throw away” and test blockchain and start over, that is only a viable option prior to initial deployment.

The best option is to create a test blockchain and then deploy smart contract code to the live environment after exhaustive testing. While this is a common solution, it only allows testers to simulate the live network, as opposed to exercising the true live environment.

Here are a few best practices to keep in mind as you exercise your new enterprise blockchain application:

  • Secure top-level support for aggressive testing: Because blockchain testing expands the scope of traditional application testing, ensure that you have the support of decision-makers to carry out these additional tests.
  • Test early and often: This is nothing new; early tests find issues and defects when they are easier and cheaper to address.
  • Design test cases in conjunction with smart contracts: Encourage — or maybe require — developers to create test cases for each smart contract function at the same time they write the code for the function. It actually is a good practice to write the test cases before they write the functional code; after the fact, test cases are almost always suboptimal.
  • Automate iterative tests: Leverage the testing tools for your development environment. Most enterprise blockchain development environments include rich testing support.
  • Leverage visualization and services: Don’t just rely on text output of test results. Use your development environment’s tools and external frameworks to visualize how well your tests are meeting their goals. Visual depictions of test results can help identify trends and save development costs by avoiding big mistakes that are hard to undo later in the project.

Blockchain offers a growing list of promises to enterprise environments. Aggressive testing of these application offerings is necessary to allow a new generation of applications to do what they promise.

Blockchain technology isn’t the answer to every problem, but it does have some interesting benefits. A positive user perception is critical to acceptance of blockchain technology at the enterprise level, and testing is the key to that positive perception.

All-in-one Test Automation Cross-Technology | Cross-Device | Cross-Platform

Article written by Michael Solomon PhD CISSP PMP CISM, Professor of Information Systems Security and Information Technology at University of the Cumberlands.

In This Article:

Sign up for our newsletter

Share this article

Other Blogs

General, Agile, Software Quality

How to Identify, Fix, and Prevent Flaky Tests

In the dynamic world of software testing, flaky tests are like unwelcome ghosts in the machine—appearing and disappearing unpredictably and undermining the reliability of your testing suite.  Flaky tests are inconsistent—passing at times and failin...

General, Continuous Delivery

What is Continuous Testing in DevOps? (Strategy + Tools)

Continuous delivery is necessary for agile development, and that cannot happen without having continuity in testing practices, too.Continuous delivery is necessary for agile development, and that cannot happen without having continuity in testing practices,...

General, Business, Software Quality

DevOps Testing Culture: Top 5 Mistakes to Avoid When Building Quality Throughout the SDLC

Building QA into your SDLC is key to delivering quality. Here are the mistakes to avoid when building quality throughout the SDLC.