Rhian Lewis is a consultant software engineer and former digital journalist at The Times who is a regular international conference speaker and panellist on all things blockchain and cryptocurrency. She launched the altcoin portfolio tracker countmycrypto.com, co-founded the London Women in Bitcoin meetup group in 2014 and has acted as an advisor and strategist on various blockchain projects for the last seven years. She blogs on cryptocurrency and is the author of The Cryptocurrency Revolution (Kogan Page) and Understanding Decentralized Finance (Kogan Page). She is based near Plymouth, UK.

How can we test the performance and scalability of our DApp on Web3, especially when it comes to handling high volumes of transactions?

Testing dApps challenges many of our assumptions about testing, primarily the idea that we can provide a controlled test environment that closely mirrors Production. Of course. It is still important to adhere to all our good practices for the non-Web3 parts of the application: if we are making requests to APIs for the non-blockchain parts of the dApp or if the front end is complex, we would apply all the normal strategies and tools that we would apply for a standard Web 2.0 application.

However, as the back end for the dApp is effectively supplied by a public blockchain, our application can only be as scalable and performant as the underlying network itself. Choice of blockchain will influence our approach: we may opt to use a Layer 2 solution, for example, rather than directly using a blockchain like Ethereum.

But sometimes all the testing in the world can’t help you. There have been several instances where Ethereum has more or less ground to a halt where the system is under a lot of pressure, such as the doomed Bored Ape Yacht Club Otherside NFT drop. In cases like this, even the best designed dApp will fail to deliver: the role of the tester in this case is to have ensured that the behaviour of the dApp when the system is under such pressure is such that it communicates to users exactly what is happening and – as far as possible – attempts to conserve the current state so that transactions can happen later. So you should always ensure your tests cover the “very unhappy path” scenario.

What tools and frameworks are available for testing smart contracts and other components of Web3 applications?

The good news is that we have a lot of choice when it comes to tools and frameworks, especially for automated tests. Most of these involve wrappers around existing test tools, or custom matchers for assertion libraries: for example, Waffle and Hardhat both provide their own versions of Mocha and Chai packaged with their one-stop development-test-and-deployment toolboxes.

Truffle, the original all-in-one Ethereum development solution, offers various choices for testing including the opportunity to run tests natively in Solidity with the `truffle test` command. Any of the frameworks I’ve mentioned could be used by someone with experience of JavaScript testing or development.

But there are also solutions based around Rust (Foundry) or Python (Brownie). Your choice of tools and language will, of course, be heavily influenced by the blockchain that your team are developing on top of and the smart contract languages that are used.

All of these I’ve mentioned are focused around testing smart contracts, but it’s also important to test the other elements that make up a dApp, including the front end. For that you could consider using Dappeteer, which is a fork of Puppeteer originally developed by the developers at Decentraland.

How can we ensure that our DApp is secure and resistant to attacks, such as denial-of-service (DoS) attacks, double-spending attacks, and others?

This is a very relevant question, when we consider the billions of dollars worth of value that has been stolen or lost from the ecosystem through hacks and bugs.There are some very simple things that developers can do to close some of the more common loopholes, such as using pre-existing secure libraries such as OpenZeppelin during development.

And there are various good security practices such as protocols around how private keys are stored and how any client funds are stored, which are not specifically the tester’s responsibility to ensure, but which are a whole-team responsibility that everyone should be involved in.

One of the most important things a tester can do is to think outside the box: if I was a hacker, how would I behave? Manual exploration and curiosity is your primary tool here.

I mention the importance of this because many of the so-called bugs that have happened in Web3 are not actually software bugs at all – they are bugs in the requirements caused by product owners failing to anticipate that people may use the application in a certain way. Many so-called exploits on DeFi exchanges have been traders simply using the smart contract as it was designed: it was just that no one anticipated they would be able to do this.

Most reputable teams will hire an audit team and also offer bug bounties to white-hat hackers because the level of complexity of smart contracts is such that the expertise needed to spot potential attack vectors goes far beyond what an average developer or tester can spot. However, we still need to rule out all the bugs we can reasonably find at an early stage of development so we are not paying specialists to find issues that could have been caught earlier.

What are some common bugs and vulnerabilities that can arise in Web3 applications, and how can we detect and address them?

If we look at a list of the biggest Web3 hacks and attacks, one thing that jumps out is the vulnerability of bridges, which are a special type of smart contract that enables value and information to be exchanged between blockchains. These are notoriously fragile – and should be approached with caution.

Another area to be aware of is issues caused by the existence of the mempool in Ethereum and Ethereum-like chains. When your transactions are public, and when there is a delay between your contracts becoming public and actually being written to the blockchain, you need to think very carefully about whether there is information there that could be exploited. Some of this may be legitimate, like MEV, but in some cases it can allow attackers to benefit from this knowledge.

In the last question, you mentioned the double spend problem, which is something that always needs to be guarded against. Using static analysis tools such as Slither is also really important for defining potential weaknesses in smart contracts.

How can we collaborate with other developers and testing experts to improve the quality and reliability of our Web3 applications since it is a bit of a wild west at the moment ?

I feel this is something that is really lacking in Web3 at the moment, especially when it comes to testers. Your Web3 testing community is definitely the sort of thing that will make a difference. The main issue is that the whole ecosystem is in its infancy, and many projects are so early-stage that they don’t even have test teams. I believe this will change organically over time, but in the meantime, communities like the one you are creating has a chance to shape the way we test dApps in the future.

What resources and communities are available for learning and collaborating on Web3 development?

Chainacademy, of course! And Web3 testing community. And I would also encourage people to check out the B9Lab Academy, with whom I have worked in the past. They have been around since 2014 and Elias, the co-founder, spoke at the very first Ethereum DevCon. They have a great Cosmos program running, among other courses. The Ethereum Foundation has a good list of links, and you should also look out for great developer relations people like Camila Ramos (Fuel Labs) and Nader Dabit (Lens), who have written a lot of excellent tutorials.

And finally, nothing beats getting your hands dirty building your own dApp, or even playing around with tools like Remix. The more people who get involved in this community, the better.

Thanks for the participation Rhian ! You rock 🤘