Private BlockChain Implementation on Ethereum — QA strategy (Testing Techniques & Tools for Essential components-Peer To Peer Networking) — Part 5

One interesting quote that I really love & it is from Lt. APJ abdul Kalaam Ajad (Former president of India) — “ Be curious, As Curiosity leads to learning, Learning leads to Knowledge, Knowledge leads to Innovation.” In today’s world, Innovation can only survive.

As I have covered Ethereum virtual machine & Smart contract testing & tools overview in my last post EVM & Smart Contract Testing Strategy so moving ahead with the trickiest component of blockchain platform which is Peer To Peer Networking (also known as P2P Networking). Let me give some insight what it is & why it is trickiest component of Blockchain platform. If you have gone through with previous posts on this topic along with some exploration of how to test decentralized application built on programmable blockchain platform then you would have definitely come across with P2P networking. I must confess that I was so scared to even pick this component as I was not having any idea about P2P networking testing. However, Once I started drill down into the deep then I found this is going to be the interesting component to come up with strategy. Assumption I am making to propose this strategy is Leader based consensus algorithm (RAFT or PAXOS) will be used to make consensus.

Let me explain you why I am saying so. P2P network testing depends upon following attributes -

  • Scalability of Network
  1. Scalability of Network — In simple words, I would say how easily network can allow to add the new nodes without hampering any performance or functional behavior.

Now the toughest part for those who has no experience in private blockchain, there is always some configuration file involves which contains the information about what all nodes are participating in the network. Whosoever has worked on any private blockchain product by now they would have seen that configuration file to get the information about the participating nodes within network. Now there are following 2 ways to test Scalability & volatility by ensuring functional accuracy implicitly -

Approach 1 ( Creating New network by adding/removing nodes)- If you know how those configuration files are being created then you can easily add & remove the nodes. Once configuration is ready then you can make the network up. Since we all know by now, All private blockchain uses consensus algorithm where Leader of network has to be elected by the participating nodes. Best way to test is — Verify who is the leader of the network of current term & remove that node first to ensure that new leader is being elected or not. If new leader gets elected then, process the messages over network by verifying that all the nodes are having same blockchain data post consensus is made. Verification of blockchain data will be covered in upcoming post.

Approach 2 (Add/remove nodes in running network) — If network is already up & running then definitely developer would have exposed some end point to access to add or remove nodes from the network. Same approach can be taken to remove Leader of the node first & verify whether new Leader is being elected or not. Then, send over the messages like register new contract, deploy contract & create new instance to invoke new functionality from those contracts.

I think providing this pointer would be suffice enough for QA engineer to come up with more scenarios around P2P networking. Interesting cases would be when number of nodes are down in such a way that leader can not be elected then how network is behaving? if possible any one does the same then please share what is the observed behavior. This would the boundary cases where processing (execution of contracts) must be stopped however this case needs to be handled in such a way that end user will get indicative message in place of any weird exception where he will seek for technical guy to debug the issue.

Now a days P2P networking has become easy to replicate by having application dockerized (containerization of application) & run those dockerized application ( What is docker Container?) as specific nodes on any operating system. One easiest way I can think of doing P2P networking testing in automated way is — to propose developers to provide you the dockerized service/application which can run within ethereum test network so that you can easily write scripts to play with those containerized application (can be considered as isolated nodes running over the P2P network). As dockerized can be easily controlled by command line commands which can be easily wrap within shell/batch script for linux/window platform respectively.

I am still exploring the possibility how can I design some framework for P2P networking testing for private blockchain however not in my priority list as P2P networking is implicitly covers by testing smart contract execution along with verification of blockchain data for all involved nodes. If any of the nodes does not have current state of blockchain along with latest messages then it is quite evident to looks for component related to P2P.

If anyone wants to know any specific area within P2P network testing, please feel free to drop the comment I will be more than happy to help you. Also, if anyone has any feedback to make this more easy to understand & help for larger community, that would also be highly appreciated.

Stay tune for the next post on how to test consensus algorithm …..

BlockChain Evangelist & Enthusiast-Building Generic Automation Framework for BlockChain DApps for Ethereum at Startup

Looking for more of the latest headlines on LinkedIn?

Discover more stories

Originally published at on April 28, 2018.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Abhishek Jain

BlockChain Evangelist & Enthusiast with 13 years of experience as Software Test Automation Architect -