We will simply use floats!’ Moon struck the student with a stick.
The student was enlightened.
”So a few months ago I finally rage quit and hacked together an alternative solution via the path of least resistance known to me: Python.
The uncluttered and readable syntax, and simplicity of getting shit done made it an obvious choice.
After all, the goal is to spend time debugging Solidity contracts, not unit tests!What started as a 4 day code bender in a dimly lit Bangkok hotel room has progressively grown and evolved, and somewhere along the way it turned into a fully fledged project in it’s own right.
So today I’m very excited to present to you…Brownie!Brownie is a robust, easy to use framework for developing Ethereum smart contracts.
Use cases include:Deployment: Automate the deployment of many contracts onto the blockchain, and any transactions needed to initialize or integrate them.
Interaction: Write scripts or use the console to interact with your contracts on the mainnet, or for quick testing in a local environment.
Debugging: Get detailed information when a transaction reverts, to help you pinpoint the issue quickly.
Testing: Write unit tests in python and evaluate test coverage based on stack trace analysis.
We make no promises.
InteractionBrownie’s console provides a simple way to perform on-the-fly testing and debugging in a local RPC environment, or interact with contracts on a remote chain.
Rather than list off all the capabilities, take a look at this video for a sample of what can be done:using the Brownie console — so simple!When working with the mainnet or one of the testnets you can set up persistent environments to save contract information between sessions, and add accounts using a MetaMask compatible mnemonic.
DebuggingIf a transaction reverts, brownie offers the following information to help you quickly locate and fix the issue:The section of source code that caused the errorEvents that fired prior to the revertA call trace showing every jump, internal and external, leading up to the revertScripting and DeploymentCommon or repetitious tasks can be automated via scripts.
Here is an example script that distributes tokens based on a json file:And here is an example deployment script for a slightly more complicated project:taken from https://github.
com/HyperLink-Technology/SFT-ProtocolWhen running unit tests you can share a common deployment script across many tests, and isolate each test by reverting the EVM state to immediately after the deployment.
This translates to time saved in both writing and executing your tests.
Which leads to the next section…Unit TestingTake a look at the first two tests from Truffle’s example project MetaCoin:https://github.
com/truffle-box/metacoin-box/blob/master/test/metacoin.
jsAnd now compare to the equivalent tests in Brownie:https://github.
com/HyperLink-Technology/brownie/blob/master/projects/metacoin/tests/metacoin.
pyThey’re very similar to read, but Brownie is notably missing calls to toNumber() and async/await wrappers.
Brownie also offers additional testing capabilities such as:skipping tests or marking them as “expected to fail”setting alerts to monitor for state changesevaluating test coverage based on stack tracesTest Coverage EvaluationBrownie gives a percentage estimate for test coverage by analyzing the stack trace of each transaction and checking which opcodes executed.
You can use this as a quick reference to make sure that you haven’t lost significant coverage after a code refactor.
Key benefits to coverage evaluation using the stack trace:Non-invasive: Littering your contract with events to evaluate coverage means your tests are now running on a different contract.
This affects gas consumption, sequence of event firing, and increases the time to run the tests.
Expression based: Within a line such as require( (a && b) || c); you can see if your tests hit all conditions truthfully and falsely.
Line based coverage reporting is insufficient when a single line can evaluate in 5 different ways.
Additionally, you can use a complimentary tool I’ve created called opview as a way to visualize your coverage:test coverage visualization with opviewGreen means the highlighted code was executed, red means it wasn’t.
Yellow and orange are for conditional statements that only evaluated True or False.
What Next?In the coming months, myself and the rest of the team at HyperLink Technology will continue to test and expand Brownie as we use it to develop our other projects.
In announcing it today, I’m inviting the greater community to try it out and offer questions, comments, criticisms and suggestions for improvement.
Issues and pull requests are welcomed!.I would love this to be a more collaborative effort and look forward to hearing from you.
Getting StartedTo get started using Brownie, you can view the source code on Github and view the documentation on Read The Docs.
.. More details