Dappeteer vs Synpress

You asked you got it !! JK 😂 , this was in my backlog for a long time and finally had time to write something about it. This literally summarises my life:

Not many people out there talking about Blockchain Tests, maybe Oleksandr Romanov and Rhian Lewis, so I usually resource to communities (Web3Tests, Synpress…) to see what others are doing.

It is a bit shocking as there are many well-known attacks in this technology and on top of that after deploying something to the Blockchain you can’t go back (immutability feature), so how come this phase is so neglected as making sure everything is alright is so crucial ?

I am doing a quick benchmark about the End-to-End Tests Web3 Frameworks that are out there, and yes you can always mock the Web3 and then you don’t rely on third party integrations, which you would do any Web2 application already. But hey, this is one option to use when you need it !

Here it is what I got from the two major and most popular tools to test Web3 Apps (DApps):

Criteria	Synpress	Dappeteer
Platform & Application Support	Web3 applications (Dapps)	Web3 applications (Dapps)
Supported Technologies	TypeScript, Javascript	TypeScript, Javascript
Wallets supported	MetaMask	MetaMask snaps, but probably is outdated.
Testing Scope	E2E Tests	E2E Tests
Testing Framework Integration	Playwright (as a plugin) Support for Cypress is coming soon.	Playwright (as a plugin) Puppeteer (as a plugin)
Ease of Use & Learning Curve	Easy learning curve, requires JavaScript/Typecript knowledge	Requires JavaScript/Typescript knowledge
Reporting & Analytics	Detailed reports with dashboards and integrations	Basic reporting, may require additional tools
Ease of setup	Easy to set up with Node.js, yarn and npm	Easy to set up with Node.js, yarn and npm
Browsers	– Chrome/Chromium (+ Edge, Opera, Brave, Chromium-based browsers) – Firefox – Webkit (Safari)	– Chrome/Chromium (+ Edge, Opera, Brave, Chromium-based browsers) – Webkit (Safari)
Community & Support	Large and active community, extensive documentation and support	Smaller community, growing resources and documentation
Cost & Licensing	Open source and free to use	Open source and free to use
Scalability & Integration	Highly scalable, integrates with CI/CD pipelines	Less information available, may require custom integrations
Accessibility	Supports accessibility testing with plugins	Information not available.
Customization	Highly customizable with plugins and extensions	Highly customizable with plugins and extensions

Let me know in the comments which option you went for and how was your experience with it 😃

Equal Experts Geek Conference 2023

Hey guys, 4 months ago I had a 5 minutes lightning talk about How the QA will look like in the future at the Equal Experts Conference.

We went through the evolution of the role and how it is right now, then we quickly talk about the trends that are coming so you can already prepare yourself to be up to date 🙂

In this 5-minute talk, we will quickly talk about the future of Quality Assurance (QA) position and discuss the evolution of the QA role in response to emerging trends.

The QA role has come a long way from its traditional focus on manual testing and bug detection. As technology advances, QA professionals are adapting to new demands and becoming integral contributors to the software development process.

The future of QA position will be marked by AI Tests, Tests in the Cloud, Web3 Tests, Alerting and Monitoring, along with strong soft skills. By embracing these trends and developing the necessary skills, QA professionals will be well-equipped to drive quality and innovation in the ever-changing software development industry.

Web3 Test Series: Lewis Prescott

Lewis Prescott

QA Lead at Cera Care (one of Europe’s fastest-growing companies). He talks about Contract API Testing: 99 minute workshops with Ministry of Testing, on Testers Island Discs and many meetups.

He provides services on how to get started with API Contract Testing, Contract Testing for Microservices, End to End Testing, Acceptance Test Driven Development!

What are contract tests, and how do they differ from smart contract tests?

Contract testing is a framework for testing integrations between two services, for example an API and a mobile app. The contract is defined by the mobile application who requests data, shares the request and expected response with the API service which verifies the implementation matches the expectations. Imagine when you start developing a feature that has frontend and backend components. They must communicate with each other perfectly, in happy path and negative scenarios. These details are usually detailed within some form of documentation, but who is verifying that both sides have implemented according to the documentation? That’s where contracts come in.

Smart contract tests are also focused on testing agreements with the terms between contracts written into code, but the difference is that the contract that is compared against to is a contract deployed to a Blockchain. Same concept as normal contract testing but this time focused on the decentralised applications (DApps) and blockchain ecosystems.

Why are contract tests important in software development, and how do they differ from smart contract tests in blockchain development?

Contract tests offer the ability to scale integration tests by using mocks and act as unit level tests. Large applications with many integration points can be verified quickly and without significant maintenance of test environments. There is plenty of logic such as http codes, required fields and error contents which can be verified via contracts without the need for heavy duty integration environments.

Smart contracts are the backbone of decentralized applications (DApps) and business logic. They help ensure that the code deployed on a blockchain accurately represents the intended business logic, functions correctly in different scenarios, and is resistant to security vulnerabilities, specially given the irreversible and immutable nature of blockchain transactions.

What are some of the challenges developers face when writing contract tests versus smart contract tests?

Contract tests has a bit overhead on setup, with provisioning the broker to store the contracts. Deciding whether you want to self host or use a SaaS solution. As well as the process shift of teams changing how they go about testing integrations. Moving from the authors of the API service writing their own tests to the consumer such as the mobile app writing tests. Often when implementing contract tests you already have integration tests, so persuading people to duplicate the effort can be a hard sell as well.

Smart Contract tests same as the Contract tests are not straight forward when you are starting specially as you need to have special knowledge to setup test networks, wallets, and tools. Another important point is the costs associated when deploying and testing smart contracts, especially when running large-scale or repeated tests. On top of those there is the blockchain specific challenges and security.

How do contract tests and smart contract tests differ in terms of the tools and frameworks used to implement them?

Contract testing most commonly uses Pact & Pactflow which supports multiple languages and frameworks such as graphql. Offering matchers and the ability to compare results makes implementing contract testing much easier. Pactflow offers a SaaS solution to store contracts securely and additional features to visualise dependents.

Smart contract tests are often implemented using dedicated blockchain development tools and language such as Truffle, Hardhat, Solidity. These frameworks provide additional features like contract deployment management, fixture data handling, and integration with test networks. Tools like Ganache provide local blockchain test networks that developers can use to deploy and test smart contracts.

How do contract tests and smart contract tests differ in terms of their level of complexity and the skills required to write them?

Contract testing gets complicated when you need to setup different states before the tests can run, for example data needs to be available within the API in order to test the specific scenario. The key skill though required is good communication and collaboration. Due to the teams now relying on each other to deploy and make changes. It’s important to communicate effectively and support each other’s changes. Contract tests also live next to the code, requiring a decent level of programming skills and knowledge of the application under test.

Smart contracts tests need to consider factors such as consensus mechanisms, gas costs, and security vulnerabilities, blockchain network, deploying contracts, and handling transactions. Additionally, skills in testing blockchain-specific functionality, such as testing for gas usage optimization and handling different network environments, are essential for writing effective smart contract tests.

Thanks for the participation Lewis ! It is always a pleasure to learn from one of the biggest leaders in the area ! 🙌

Web3 Test Series: Oleksandr Romanov

Oleksandr Romanov

Oleksandr Romanov is a Software Engineer in Test / Software Engineer from Dnipro, Ukraine.

He has 11+ years of experience in testing and test automation. His main area of expertise is building and leading test automation processes. He has worked with banking apps and payments services, CMS systems and mobile games. At the moment he is responsible for test engineering for a complex blockchain and blockchain-based applications.

He loves to share his knowledge in the form of articles and conference talks. Currently he contributes to these projects:

How can developers get started with building DApps on Web3, and what are some best practices to follow?

Decentralized applications in a nutshell very similar to the regular applications. From frontend part it is not different at all. The difference starts with the backend part. You need to learn what is blockchain, how it works, how to store data on-chain, how to create smart contracts and use oracles to fetch data from the world.

Best practice is to test smart contract code before the release. Due to the nature of blockchain, you can’t easily change the code after the release. That’s why in case of a bug, you have a huge risk to loose a lot of money and user’s credibility. Thus you need to put a lot of effort to test business logic and security of smart contract as much as possible.

What are some of the current trends and developments in Web3, and how might they shape the future of the internet?

Trends and developments in Web3 can be split into to major groups.

First, there are totally new things – available and used mostly at the blockchain world: decentralized identities, zero-knowledge proofs, tokens and NFTs.

Second group – are the projects where people want to move successful business model from a Web2 to Web3 world. In some cases it is almost one-to-one movement, in other – it results in a totally new models. One of examples here are projects from the decentralized finances sector and any project with a prefix “decentralized-”: web browsers, social media and video hosting platforms, file hosting like IPFS and many many others.

What are the most important things to test when building a decentralized application (DApp) on Web3?

Functionality. One of the biggest differences building DApp is that you as an engineer do not have a full control of your backend – it is distributed among ten of thousands of computers around the world. The blockchain is constantly evolving and you to be aware of changes and how they can affect your application.

That’s why you need to understand how your application deals with the blockchain, how data is stored and retrieved, how pays the fees, how you present on-chain data to your customers. The deeper your knowledge of a particular blockchain – the less obvious bugs you will encounter at your DApp.

Security. When dealing with decentralized applications the majority of bugs come from the purely written smart contracts (or any code working with the blockchain). Hundreds of millions of dollars are lost due to neglecting the question of security for DApps. You can check some (not all) known hacks for Solidity at solidity-by-example resource.

So in-depth security testing are the must-have for such applications. There are security testing tools like Slither, Echidna, Manticore, MythX available. But as any security tool – they can’t provide 100% security guarantees. Additionally, there are separate companies or people who do security audit for smart contracts.

Performance. You should also understand how DApps behave in terms of the performance. As blockchain of the DApp is partially or fully stored at the blockchain – you don’t have a direct influence at the performance of the network. So you need to build usef flows in such a way that application should be blocked until transaction is stable. Stability or correctness can be checked as side – process. But it is all depends on the type of the DApp.

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

In Ethereum world the standard frameworks are Hardhat, Truffle or Brownie. All of them have nice toolset for keeping contracts testable and observable.

If you want to use some other programming toolset for smart contract development – it is possible to simulate the network locally using Ganache.

The testing of the Dapp can be split onto various levels.

Unit tests for the frontend usually created by the developers in Javascript / Typescript
Unit tests for the smart contracts can be done using Solidity or Javascript. Or Python if you use Vyper.
Integration tests are usually implemented in Javascript as well. Hardhat for example offers integration with Mocha out of the box.
UI tests can be created at any available language, but in case of JS stack – it can be plain old Selenium WebDriver or it’s fancier competitors – Playwright or Cypress.
- For wallet integration (like Metamask) there are some libraries available: synpress, dappeteer

How does Cardano Blockchain differ from other blockchain platforms like Ethereum?

Cardano has a lot of differences from other blockchains available on the market.

Transaction model. instead of account-based transaction model (like in Ethereum), Cardano has UTXO model – similar to Bitcoin’s. More precisely – an extended UTXO model.
Tokens. You don’t need to create special smart contracts to get new tokens on Cardano. Here tokens are natively supported along with the native currency – ADA.
Consensus protocol. Cardano uses “Ouroboros” proof-of-stake protocol (in some variations) from the launch date. So the chain itself much greener and consumes less energy for producing blocks. Ethereum has only recently switched to proof-of-stake.
Upgradability. It was a long and hard road, but now it is possible to update the main chain and protocol almost instantly and without a risk to get issues or a big forks.
Formal Verification. All new major technical improvements to the chain starts as a whitepapers and then formally proved by a scientist community. Only after that it become a code.

What programming languages and development frameworks are used for building applications on Cardano?

At this time the main programming language for creating smart contracts at Cardano is Plutus. It is a Haskell-like language, that allows to build and test smart contracts before they are deployed. You can start to dig into Plutus from the documentation page. From the first sight Plutus may seem like a hard one – but it offers a better security and auditabilty comparing to Ethereum’s Solidity.

In addition to Plutus, you can try Marlowe – the domain-specific language for financial contracts. It can work either with Haskell or with Javascript.

If you want to learn how to create smart contracts using I can also recommend the Plutus Pioneer Program course. For better understanding you check a prerequisite course on Haskell.

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

Official documentation is the first source of information about a particular blockchain or technology. Additionally, each major blockchain projects has it’s own forums and Discord communities.

If you have some background in programming language, I can recommend the following resources:

Learn Blockchain, Solidity, and Full Stack Web3 Development with JavaScript – 32 hours of highly practical knowledge on how to work with Solidity and JS for creating DApps. And it’s totally free.
Blockchain Developer roadmap – collection of topics and blog posts about blockchain development
The Ultimate Smart Contract Developer Roadmap another good roadmap to learn from scratch

From testing point of view – I definitely can recommend Web3 tests community. It is a very young community, but will be useful for those who want to understand testing in blockchain a little deeper.

Also – you can check Awesome Blockchain Testing repo in search for posts and whitepapers on testing in blockchain.

To get a glance on how testing is done for Plutus on Cardano – check out Testing Plutus Smart Contracts series of blog posts.

Thanks for the participation Oleksandr ! Amazing interview and a leader to follow in the web3 area! 🚀

Web3 Test Series: Rhian Lewis

Rhian Lewis

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 🤘

Web3 Tests Series

Hey there ! Are you ready to dive into the world of Web3 testing? We’re about to take a deep dive into the exciting and ever-evolving world of blockchain technology.

Web3, or the third generation of the internet, is a term used to describe a new era of the web that is focused on decentralization, security, and user privacy. Unlike the current web (Web2) which relies on centralized servers and applications, Web3 is built on decentralized technologies like blockchain and peer-to-peer networks.

This means that instead of relying on a central authority to manage and store data, Web3 relies on a network of users and nodes to collectively verify and manage transactions. This decentralization creates a more secure and transparent web, where users have more control over their data and can trust that their personal information is being handled safely.

One of the key technologies driving Web3 is blockchain. Blockchain is a decentralized ledger that records transactions across a network of computers, making it virtually impossible to hack or alter data. This makes it a perfect fit for Web3 applications, where security and transparency are essential.

Another important aspect of Web3 is the focus on user privacy. With the current web, users often have to sacrifice their personal data in order to use online services. But with Web3, users can maintain control over their data and choose what information they want to share.

Overall, Web3 is a promising new era for the internet that puts users back in CONTROL of their data and creates a more SECURE and TRANSPARENT web. From testing smart contracts to decentralized applications (dApps), there’s always something new to learn and explore.

So, if you’re a fellow Web3 enthusiast, or just someone who loves a good challenge, be sure to follow my upcoming posts. I’ll be chatting with some of the leading minds in the industry and sharing their insights.

Until then, join our Web3 Testing Discord Community or our Twitter and stay curious🔥

E2E Tests for Web3 Applications (TestJS Summit 2022)

It is out 🎉🎉

If you are curious to know about web3 and how can you test it, here are some ideas!

We will go through a brief explanation of what is Web3 and the architecture of a web3 application. Then we will talk about how to do end-to-end tests, its challenges, some test tools that are available, and 2 demos using Synpress and mocking the web3 layer.

The agenda is:

– What is Web3;

– The Architecture of a Web3 Application;

– Web3 E2E Tests Introduction;

– Web3 E2E Tests Challenges;

– E2E Test Tools;

– Demo.

https://portal.gitnation.org/contents/e2e-tests-for-web3-applications

It took me ages to record this video, not going to deny, I am still improving my video editor/design skills… I even bought a new mic to help me and would love to have some feedback about the talk in general.

If you have literally 5 seconds, here is the link.

The big news is, we have created a Web3 Tests Community on Discord !

Yes, me and Jakub, one of the creators of Synpress, are on that and we are looking for contributors and members (of course) 🙂

Yes, I know… We have too many places to create a community nowadays 😩, but this one is going to be one for all of our Web3 Testing people.
Still in the beginning so bear with us while we build and share the content.
Join and share 🤩

Blockchain Tests Workshop at The National Software Testing Conference

Hello guys, here are the slides from the workshop on Blockchain Tests that I gave earlier this week, as well as some responses to the issues that were addressed during the session. I can say as my first presential workshop after pandemic, it was a great experience with a full room 😃

Unfortunately, there is no recording of it, but you may clone the repo and follow the coding instructions to build the test class and methods, then compare to version 2 of the project, which has the most recent version.

Introduction to Blockchain Tests Workshop at The National Software Testing Conference 2021 from Rafaela Azevedo

What is the Required() function in Solidity?

The require Solidity function guarantees validity of conditions that cannot be detected before execution. It checks inputs, contract state variables and return values from calls to external contracts.

Where the Address type comes from ?

The address type comes in two flavours, which are largely identical:

address: Holds a 20 byte value (size of an Ethereum address).
address payable: Same as address, but with the additional members transfer and send.

The idea behind this distinction is that address payable is an address you can send Ether to, while a plain address cannot be sent Ether.

Type conversions

Implicit conversions from address payable to address are allowed, whereas conversions from address to address payable must be explicit via payable(<address>).

Explicit conversions to and from address are allowed for uint160, integer literals, bytes20 and contract types.

Other tools that you can use to test Blockchain applications

Ethereum Tester,
Hyperledger Composer
Exonum test kit
Embark
Populus
BitcoinJ
Binance

Resources

Blockchain Tests with Truffle (Solidity)

Hello guys !! After my talk about Testing Blockchain Applications on the #TechKnowDay, I thought it was worth posting a guide on the same topic as I felt it was complex to also understand Blockchain. So, this is a quick tutorial on how to run tests with Truffle Framework.

https://youtu.be/FKoKaugeSBE

If you are still wondering where you can use Blockchain, here it’s a table with the percentage of companies that are focusing on it and the use cases.

https://101blockchains.com/blockchain-implementation-strategy/

Requirements

We are going to use a bit of Javascript for the web part and Solidity for the blockchain project. For this project you will need to have installed NPM and Node already. We are going to install Truffle as part of the setup. You will also need MetaMask and Ganache, all of them you can find bellow:

Setup your Local Ethereum Blockchain

Open your MetaMask plugin and click on new Custom RPC Network. Type the following (Currency Symbol will be automatically populated after you type the Chain ID) and save.

Open Ganache, click on Quick Start (Ethereum). Double check if the server has this configuration clicking on the on top right and then Server tab.

Click on Show keys of the account you have created and copy the private key.

Back on MetaMask, click on Import Account and add the private key you have copied from the previous step.

Setting up the project

On your terminal run:

npm install -g truffle

If you want to follow the test steps only, then you need to download the first release that contains the installation files of the project already:

https://github.com/rafaelaazevedo/PetShopTestWorkshop/releases/tag/1.0

If you want to try the installation for yourself from the scratch, then just go to this link and follow the Getting Started guide. This guide won’t be focusing on the installation of the framework or the setup of the contracts and migrations.

Just a heads up that for this project I am using the pet-shop box instead of the MetaCoin from the Getting Started guide.

Installation

After downloading the project, you will need to run some commands to set it up. Open your terminal on the root of the project and run:

Run the development console

truffle develop

Compile and migrate the smart contracts. Inside the development console you don’t need to type the truffle command.

compile
migrate

To get out of the truffle console type

.exit

Create a new file inside of the test folder called TestAdoption.sol and import all the needed modules, such as assertions, new instances of deployed addresses and the contract that will be tested.

pragma solidity >=0.5.0;

import "truffle/Assert.sol";
import "truffle/DeployedAddresses.sol";
import "../contracts/Adoption.sol";

Then create the class and inside add the variables:

adoption that will get the Adoption contract that was deployed
expectedId this one will be the id of the pet under test (You can get the id of the pet you want to test from this file)
expectedAdopter which is the address of this current contract that we are creating in the next function

contract TestAdoption {
    Adoption adoption = Adoption(DeployedAddresses.Adoption());
    uint256 expectedPetId = 8;
    address expectedAdopter = address(this);
}

Testing

Asserting the adoption

Add the testUserCanAdoptPet() function below the variables block.
Note that here you are creating a function that will test you can adopt a pet and for this you will need to get the address related to the adoption transaction and compare the returnedId with the expectedPetId address
Try to explore and add other asserts like checking if it’s not returning null.

function testUserCanAdoptPet() public {
        uint256 returnedId = adoption.adopt(expectedPetId);

        Assert.equal(
            returnedId,
            expectedPetId,
            "Adoption of the expected pet should match what is returned."
        );
    }

Asserting the adopter of the pet

Add the testGetAdopterAddressByPetId() function below the previous function.
This function will check if the adopter address for that pet is the same from the adopters list
Try to explore and add other asserts like comparing the age of the pet is returning correctly, for that you would need to add the age on the Adoption.sol contract, then compile and migrate again.

function testGetAdopterAddressByPetId() public {
        address adopter = adoption.adopters(expectedPetId);

        Assert.equal(
            adopter,
            expectedAdopter,
            "Owner of the expected pet should be this contract"
        );
    }

Asserting the list of adopters

Now add the testGetAdopterAddressByPetIdInArray() function below the previous function.
This function will check if the memory address for this petId is the same as the expectedAdopter
Almost the same test as before, but this time we are explicitly storing adopters in memory rather than contract’s storage and then comparing them.

function testGetAdopterAddressByPetIdInArray() public {
        address[16] memory adopters = adoption.getAdopters();

        Assert.equal(
            adopters[expectedPetId],
            expectedAdopter,
            "Owner of the expected pet should be this contract"
        );
    }
}

You should have something like this:

pragma solidity >=0.5.0;

// The first two imports are referring to global Truffle files, not a `truffle` directory.
// Gives us various assertions to use in our tests.
import "truffle/Assert.sol";

// When running tests, Truffle will deploy a fresh instance of the contract being tested to the blockchain.
import "truffle/DeployedAddresses.sol";

// The smart contract we want to test.
import "../contracts/Adoption.sol";

contract TestAdoption {
    // The address of the adoption contract to be tested
    Adoption adoption = Adoption(DeployedAddresses.Adoption());

    // The id of the pet that will be used for testing
    uint256 expectedPetId = 8;

    //The expected owner of adopted pet is this contract
    address expectedAdopter = address(this);

    // Testing the adopt() function
    function testUserCanAdoptPet() public {
        uint256 returnedId = adoption.adopt(expectedPetId);

        Assert.equal(
            returnedId,
            expectedPetId,
            "Adoption of the expected pet should match what is returned."
        );
    }

    // Testing retrieval of a single pet's owner
    function testGetAdopterAddressByPetId() public {
        address adopter = adoption.adopters(expectedPetId);

        Assert.equal(
            adopter,
            expectedAdopter,
            "Owner of the expected pet should be this contract"
        );
    }

    // Testing retrieval of pet owner storing getAdopters in memory
    function testGetAdopterAddressByPetIdInArray() public {
        // Store adopters in memory rather than contract's storage
        address[16] memory adopters = adoption.getAdopters();

        Assert.equal(
            adopters[expectedPetId],
            expectedAdopter,
            "Owner of the expected pet should be this contract"
        );
    }
}

Running the tests

Open your terminal on the root of the project and run:

truffle test

If everything went okay you will see green checks on your terminal like this:

You can check the final code with the latest release (Spoiler alert: You will see pictures of my dog, my dog’s best friend, my friend’s cat and my previous dog)

git clone git@github.com:rafaelaazevedo/PetShopTestWorkshop.git

Open a tab on your terminal and run the development local server

npm run dev

You can also check truffle config file to check the host and port where we are running the project and edit if you need to.

Releases of the project:

Release 1.0 Contains the Solidity contracts and Truffle Migrations only (No UI)
Release 1.1 Contains the Solidity contracts, Truffle Migrations and Truffle Initial Tests only (No UI)
Release 1.2 Contains the Solidity contracts, Truffle Migrations, Truffle Initial Tests and Initial UI
Release 1.3 Contains the Solidity contracts, Truffle Migrations, Truffle Initial Tests, Final version of UI

Testing Blockchain Applications

Hello all, today I am going to post about a topic that I am a huge enthusiast about: Blockchain !

Nowadays data is one of the most valuable product that you can own, and as we are surrounded by fake data coming from thousands of different places, it is hard to know what is trustworthy or not.

What is Blockchain ?

It is basically the second phase of the internet. The Internet democratized the exchange of information, blockchain promises to democratize the exchange of real value. It was created in 2008 by Satashi Nakamoto, which the identity is still unknown.

An example of how blockchain can be used is when you want to make a transaction of £10 from a X to Y. Nowadays what happens is this transaction goes through a third-party app or payment processing system. Then, X’s bank will need to check the details of Y’s bank and once this is done the transfer of the amount will initiate with a certain amount of deductions, of course. In the end both banks will record the transaction deducting the transaction fee, meaning Y will receive something like £9.95. Even though this process is quite secure and has many redundancies in place to make sure that it stays secure and accurate, there are some basic fundamental issues with this process:

Delay in processing (using this middle agent and all the bureaucracy)
Dependency on a single intermediary whose effectiveness is never 100 percent (dependency on a national state)
In case of any gap in the transaction, no one takes the responsibility and people keep on blaming each other (not concrete proof to check the transaction)

Blockchain is a system where you no longer have to worry about these problems, you just need to perform a transaction and there is a chain of people who are able to validate your transactions every second. This mechanism is called as Proof of block and this is done based on the public key provided for the encrypted data, and it is done by all listeners in the peer-to-peer network. They are real people/identities, not bots. Since there is not a single transaction validating authority (banks, national state) who are centralising the transaction service, the process is effectively decentralized, public and transparent for everybody to see.

Once a specified number of people validates the transaction, the transaction details are stored in the form of a block and that block is added to the existing blockchain. Once the blocks are validated, nobody can change them, just add another one on top, they are immutable. These blocks have a specific hash associated with every block. These hashes are like fingerprints and are unique to every block. Every person that is validating the transaction process is called a miner. The more miners, the better efficiency of the transaction.

A block contains data, a hash, and the hash of the previous block. Since it contains a hash of a previous block, all the blocks contain data for the previous blocks and it becomes almost impossible for a blockchain to be corrupt.

What types of tests can I perform in a Blockchain app ?

API Testing: In API testing, we ensure that the interaction between applications in the blockchain ecosystem is as expected
Block/Peer/Node Testing: All the blocks on the Network should be tested individually to ensure proper cooperation. All diverse nodes on the Network must be tested independently to ensure smooth cooperation. Do the nodes in the network sync with other validating peers? Is the integrity of the network and shared ledger maintained throughout the testing?
Functional Testing: In Functional Testing, we evaluate the work of various functional parts of the Blockchain (e.g., smart contracts).
Performance Testing: Details like network latency based on block size, network size, expected transaction size, and how long a query takes to return the output with the specialized authentication protocol
Security Testing: Here, we ensure that the application is not vulnerable to attacks and the systems can protect the data and are capable of handling malicious attacks, etc.
Integration Testing: In Integration testing, we ensure that all the components of the application are integrated properly and performing the actions appropriately
Smart Contract Testing: Smart Contract testing is about performing detailed functional testing of business logic and process. It refers to the set of software constructs that automatically execute transactions when predefined conditions and business logic are met. Testing smart contracts involve simulation of all possible expected and unexpected variables for every contract and the triggers that execute transactions.

Benefits of Blockchain Apps

Decentralized System: No need to have a middle agent for the transactions. Beneficial in various industries like finance, real estate etc.
Better Security: As it uses multiple nodes to complete and authenticate transactions, you don’t rely only on a transaction system that is controlled by a centralized group of identities.
Authenticity: Allows the unique algorithm to process data, like a fingerprint.
Increased Capacity: Increases the capacity of the entire Network as it is completely decentralized and real people can verify the blockchain.

Challenges in Blockchain Testing

Understanding the Technology: Blockchain is a new technology and understanding it is very important in order to test it. Where does regulatory compliance overlap with quality? How do you fix a defect that has been deployed as part of an immutable smart contract? How do you predict transaction fees and determine the correct behaviour of your application if transaction fees and network volume increase unexpectedly?
Lack of Blockchain Testing Tools: Blockchain-based applications testing is all about tools. Selecting the right tool as per application is one of the important decisions.
Defining Test Strategy: Designing Test Strategy for Blockchain application is quite complex exactly because you need to have a good understanding and in-depth knowledge of the technology.
Block and Chain Size: Testing for block size and chain size is quite important as the application may fail without proper validation of block size and chain size and creating a false-positive verification.
Integration Testing: Should be done properly and frequently to test that all the components are properly integrated.
Performance and Load: You need to perform load testing to give better insight into how the Blockchain application performs in the real world, check if it is scalable and what are the limits. Check the example that was done to Ethereum and the Cryptokitties.
Security: Securing the data should be the most important thing in a Blockchain Application, to be honest, in any application. Even bitcoin is not bug free !

What do you need to consider when testing a Blockchain Application?

Here it goes an example with Bitcoin transaction tests:

Block Size: The maximum fixed limit of a block is 1 megabyte. After the introduction of Bitcoin, the average size of a block for the first 18 months came out to be under 30 KB. But in December 2017, it hovered around 1 MB. What if the size of a block exceeds beyond 1 MB?
Chain Size: There is no limit on the size of the chain. So, it is fun to test it for its function and performance. For example, the Bitcoin chain’s size keeps on increasing day by day.
Load: With so many people on the blockchain, the load becomes a major parameter to test in a blockchain. Bitcoin currently has a maximum throughput of 3.3 – 7 transactions per second, but what if the transaction/second increases as in the case of Visa(2000), Paypal(193), etc? The load remains a major problem with blockchain because performance drops when the load increases.
Security: Since there are many miners involved with a transaction, ensuring security is a little complex. Well, there is a multi-layered security system in a blockchain. If one of the layers has been hacked, the instantaneous transactions cannot be stopped. It is, therefore, to be tested that one security layer doesn’t affect the other.
Transmission of data: Encrypted and decrypted data is transferred from computer to computer, so it is necessary to test if the transmission process is working flawlessly. Is the data being sent received on the other end, or is there a loss in between?
Addition of block: Every new block is added to the chain once the transaction’s validity is authenticated. So, it must be tested that there should not be any leak in the block addition system and the block must be added after authentication.
Cryptographical data: Cryptography is the backbone of blockchain technology. Therefore, it is necessary to make sure that the data is properly encrypted and decrypted.

Blockchain Testing Tools

Ethereum Tester: It is an open-source testing library available as a Github repo. Its setup is pretty easy with a manageable API support for various Testing requirements.
BitcoinJ: It is a Java-based framework built for Bitcoin-based apps that enables you to interact with the real BTC network and various testing activities. In order to use it, you don’t have to download the standard BTC Core files from Bitcoin.com. You can even approach a user forum in case you need clarification or are facing hiccups in the testing process. It is an open network available for assistance.
Populus: This framework has the testing functionality of Ethereum embedded in the form of a set of features for test contract deployment. It’s developed around the py.test framework. Hence, it is relatively easy to implement.
Truffle: It’s a commonly referred name for Ethereum developers, which brings in good testing features, such as automated contract testing. The framework holds capabilities beyond just testing functionality within the Blockchain application.
Embark: It is a testing framework that focuses on developing decentralized applications (dApps) that run on various systems or nodes. It has integrations with Ethereum blockchain, IPFS, and a decentralized communication platforms such as Whisper and Orbit.

Future of Blockchain

Even though Blockchain is often discussed in financial services and cryptocurrencies, this technology offers a broader range of potential applications. The use case of Blockchain technology is picking up pace in various industries and segments. A World Economic Forum report predicts that by 2025, 10% of Global Gross Domestic Product (GDP) is stored on Blockchains or Blockchain-based technology.