Rigorous testing for ensuring code correctness
ShapeShift employs a comprehensive testing procedure before implementing any trading or swapper system upgrades.
Automating testing without additional overhead
With DevNets, ShapeShift engineers can spin their own private networks prefilled with test tokens and with fresh states of 30+ networks.
"I thought it had to be a way to simulate transactions before sending them on-chain. So, a ShapeShift community member recommended Tenderly, and that's how we started using it.”
Senior software engineer and core contributor at ShapeShift
Founded in 2014, ShapeShift first started out as a trading tool in the wake of the Mt. Gox hack, believing that third-party intermediaries shouldn’t hold customers’ funds. Over time, they evolved into an all-in-one crypto trading platform.
As the space continued to evolve and DeFi emerged as an innovative way to manage finances without an intermediary, the founders realized that the model of decentralized exchanges (DEXs) is much closer to their initial vision. So, in 2020, ShapeShift started to sunset its trading engine and launched a DAO.
ShapeShift is now an open-source DeFi dapp, serving as an interface between users and their wallets. It’s community-owned, non-custodial, free, and decentralized, embodying the values of Web3 at its very core. Since their interface runs on IPFS, users can even host it locally. Also, ShapeShift supports 12 chains and more than 170 wallets, bringing DeFi closer to a wide range of users.
The ShapeShift testing process
Their ShapeShift core team of developers integrated LI.FI. into their platform. With this integration, they added additional routes to the existing ShapeShift cross-chain swaps, bringing more comprehensive trading capabilities to their users.
However, such upgrades are difficult and expensive to test. For instance, whenever they update the swapper system or change the logic of handling trades, fees, inputs, or outputs, they need to test everything out to ensure it executes as expected.
So, even back in the day, the ShapeShift developers looked for a way to validate their solutions before going into production.
“I thought it had to be a way to simulate transactions before sending them on-chain. So, a ShapeShift community member recommended Tenderly, and that’s how we started using it”, says Woody, a senior software engineer and core contributor at ShapeShift.
What the ShapeShift testing flow looks like
So, to confirm the validity and correctness of their upgrades, the ShapeShift team employs stringent testing procedures. Their test suite consists of unit, integration, and end-to-end testing, both manual and automated.
The ShapeShift testing process starts with unit testing, followed by integration and then end-to-end testing. The team first initiates automated testing and then moves on to manual testing for a comprehensive code review.
As part of the manual testing process, the ShapeShift engineers spin up their app in a remote or local environment. Then, they closely inspect and double-check the code by doing a regression test. Once the engineering team gives their approval, the upgrade goes into a staging environment. As the final step, their Ops team performs another final revision.
The challenges of standard testing procedures
While performing their extensive testing procedures, the ShapeShift developer team came across multiple challenges:
- They have to invest a lot of time into manual testing, most of which are very basic and limited types of tests.
- Even with manual testing, the costs keep increasing, putting a major overhead on their team.
- It also proved difficult to automate cross-chain testing without actually forking an entire network and simulating its real-time behavior.
- With end-to-end testing, they need to be careful not to get caught in the loop of writing tests that would always work. When mocking out parts of the network in this stage, it’s easy to write tests that are guaranteed to pass because you can easily code your assumptions into your tests.
- End-to-end testing is also quite limited, limiting the ShapeShift engineers to testing only the basic functionalities of their platform.
“The type of things you can test with end-to-end testing without Tenderly is very skin-deep stuff that doesn't really matter as much. So, for example, if you're running an end-to-end test without Tenderly, you can test items like – can you switch between dark mode and light mode? Can you open and close this menu? Or does your wallet connect properly”, explains Woody.
Tenderly DevNets: a zero-setup testing solution
Striving to further resolve the challenges of running standard manual and automated tests, the ShapeShift engineering team integrated Tenderly Developer Networks (DevNets). Using this managed, zero-setup environment, ShapeShift eliminated the need for running a high number of tests manually and dealing with the lengthy setup and revision process.
Instead, the ShapeShift team runs a Tenderly yarn command to automatically spin up a DevNet and different proxies locally. Then, once they run their app, it runs through a proxy and redirects requests to Tenderly.
How DevNets improve testing
Using DevNets, Shapeshift developers can develop, deploy, and test their smart contracts against the most recent state of a selected network. This means they can spin their own private networks with production data, yet still have control of local development and testing.
After spinning up a DevNet, the team can just jump into their testing process and not worry about test tokens. Each DevNet environment has 100 test tokens and can easily be topped off using an unlimited faucet.
Additionally, Tenderly DevNets open a range of other possibilities:
- The ShapeShift team can create reusable templates with fresh states without manual configuration.
- They can also automate DevNet creation using the Tenderly CLI.
- With custom RPCs, the ShapeShift engineers can change blocks, states, contract codes, timestamps, and other parameters.
- The team can run their tests against the latest or historical states of more than 30 supported networks.
- They can use DevNets in their local development or as part of their CI pipeline.
How DevNets simplify debugging
While using Tenderly DevNets for testing, the ShapeShift developers can also access Tenderly Debugger if they come across any issues. The seamless integration enables them to quickly inspect any bug in detail and apply a fix.
When it comes to diagnosing failed transactions, the ShapeShift team already uses Tenderly Debugger in combination with Transaction Simulator. This way, if some of their transactions aren’t going through, they resimulate them in Tenderly. Then, they use Debugger to go through stack traces and identify the exact cause of an issue.
Want to optimize your debugging flow? Check out this video to learn how to use Tenderly Debugger and Transaction Simulator to identify bugs and validate your solutions. 👇
Rigorous testing: a road to foolproof Web3 solutions
The ShapeShift engineering team ensures the integrity of their DeFi solutions through extensive, rigorous testing. However, their testing process shouldn’t be an overhead for their team and prevent them from focusing on building innovative products.
With Tenderly DevNets, they’re able to speed up and simplify development and testing, while ensuring the correctness of their smart contracts and the validity of their upgrades. Additionally, with other Tenderly features readily available, the team can quickly address any issue before going into production.
So, if you’d like to optimize your testing process and get the support you need so you can focus on the creative part of building in Web3, give Tenderly DevNets a try. Start testing the easy way!