Web3: How to Test Frontend Applications?

Web 3 represents a new concept of architecture as well as a new business model of web apps. Their decentralization brings more freedom and independence, but also better possibilities for security. That makes the role of testing even more important during the development of web3 applications. It has its specifics in comparison to web 2.0 - new tools and methods, but also new issues. Which are these?

Even though testing is shifting left within the development cycle, we need at least some part of the developed application for testing. How a web3 app is developed was described by Jakub in this article. If you are complete beginners to web3, I recommend starting with the technological stack that was perfectly described by Nader Dabit.

For the sake of clarity, I will mention that all tools that I use work with Ethereum blockchain. However, the presented principles work the same for Solana, Tezos and others. In this article, I will focus on testing web3 apps, connection to the wallet, interactions with smart construct, external databases and file systems, but I will not be addressing testing of smart contracts.

What makes testing of web3 different?

To make it simple, I say about web3 that in comparison to web 2.0, we switch Facebook login to Metamask. Those of you who are aware of the web3 stack already guessed that the biggest difference is in decentralization. That is something that by definition constitutes a challenge for testing. Setup of the environment, testing data or accounts is a lot more difficult.

That is one of the reasons why web3 tools for testing are different. The testing basics, however, remain the same. The tester has to make sure that the app corresponds to the design (visual testing), if it corresponds to the specification (functional testing), if it is compliant with accessibility requirements (accessibility testing) or whatever is defined within the testing strategy.

Working with test nets

Web3 applications are typically working with smart contracts that are running on blockchain (in our case Ethereum Mainnet). However, during web3 testing we do not want to work with real ethereum and pay relatively high gas fees for each testing transaction.

For this purpose, there are Testnets. These are basically an integration environment where developers can deploy smart contacts and that they subsequently connect to web3 apps.

In order for everything to work correctly, it is necessary to switch your crypto wallet to the given testnet. In the Metamask settings, you have to allow the displaying of testnets and after that you will be able to switch to any of the pre-set ones.

The last question is how to get testing ethereum. This is covered by faucets that make it possible to add ethereum as you please. Every Testnet has their own facet.

Another possibility is to create a local network and not to be dependent on a Testnet, which gives you a lot more control over the whole network. In order to create a network, we will use Ganache. After startup, I will get directly to the created local Testnet together with accounts and 100 ETH to begin with.

We can deploy smart contracts to our local network easily using the tool Truffle. 

Testing web3

Now we should have a testnet (or a local network) and we have it connected to a web3 application. The testing process depends on the app, functional requirements and testing strategy. However, we should always test the connection to the crypto wallet. We have to think of a positive as well as negative test – what happens after a successful confirmation or alternatively after a rejection?

After that it is necessary to test the interaction with the smart contract. It is good to think about not only how the application will behave after a successful confirmation of the transaction, but also what happens when the user denies the transaction in the wallet. Or when the user allows the transaction but does not have enough ethereum.

Finally it is appropriate to verify how the web3 app reacts to changes in blockchain (for example new transactions) or how it behaves in the case that the transaction is stuck (it is staying long in pending status). If you use one of the public testnets, you can easily verify the status of your transaction via EtherScan.

Lastly, we will focus on external services and interactions with them. Does your web3 application save any off-chain data (for example into IPFS or arweave)? In that case it is advisable to check whether the data is successfully saved, the transaction connected and last but not least that the data is correct.

In case that your app is getting some data from oracles (for example Chainlink or Flux), it is good to test how the application reacts to request failure or the unavailability of the oracle.

Can web3 Testing Be Automated? 

For the sake of clarity I have to mention that we are still talking about dApps and we are primarily interested in E2E testing. The current industry standard for automated E2E web testing is Cypress, which we have been using in Ackee since 2018.

The main obstacle for Cypress was until recently the interaction with the crypto wallet. Most of them (including Metamask) are working as an add-on to the browser. Those are very hard to work with in Cypress. Luckily, in 2020 Synpress came, a cypress wrapper that uses puppeteer for direct interaction with Metamask wallet. That allows direct communication with the wallet, authorizing access or transactions. 

The direct competitor of Cypress called Playwright has direct support for Chrome add-ons. In case you have practical experience with Playwright and Metamask, make sure to let me know. 🙂

Conclusion

Testing of web3 applications brings two major issues. The first one is the new technological stack and decentralization which changes how users use apps and how testers need to test them. The second is the portfolio of tools which is still relatively limited. Web3 apps are at the beginning of their era. And testing, similarly to web 2.0, is slightly behind development. However, new tools and methods are surfacing literally every month and should be part of the QA of each web3 project.