Security News
The Unpaid Backbone of Open Source: Solo Maintainers Face Increasing Security Demands
Solo open source maintainers face burnout and security challenges, with 60% unpaid and 60% considering quitting.
PRBTest is a modern collection of testing assertions and logging utilities for Solidity, and is meant to be a drop-in replacement for DSTest.
address
, bytes
, bytes32
, int256
, string
and uint256
First, run the install step:
forge install --no-commit paulrberg/prb-test@0.2.1
Your .gitmodules
file should now contain the following entry:
[submodule "lib/prb-test"]
branch = "0.2.1"
path = "lib/prb-test"
url = "https://github.com/paulrberg/prb-test"
Finally, add this to your remappings.txt
file:
@prb/test/=lib/prb-test/src/
yarn add @prb/test
# or
npm install @prb/test
If you're starting a project from scratch, the easiest way to install PRBTest is to use my Foundry template, since it comes pre-configured with PRBTest.
Once installed, all you need to do is import PRBTest
and inherit from it in your test contract. PRBTest
comes with a
pre-instantiated cheatcodes environment accessible via the vm
property. It
also has support for logs.
// SPDX-License-Identifier: UNLICENSED
pragma solidity >=0.8.0;
import { PRBTest } from "@prb/test/PRBTest.sol";
contract MyTest is PRBTest {
function testExample() external {
vm.warp(block.timestamp + 100);
emit Log("Hello World");
assertTrue(true);
}
}
All assertions have overloads with an additional err
argument, so that you can pass custom error messages.
Name | Argument Types |
---|---|
assertTrue | bool |
assertFalse | bool |
assertEq | address , bytes , bytes32 , int256 , string , uint256 and their array equivalents |
assertNotEq | address , bytes , bytes32 , int256 , string , uint256 and their array equivalents |
assertAlmostEq | int256 and uint256 |
assertGt | int256 and uint256 |
assertGte | int256 and uint256 |
assertLt | int256 and uint256 |
assertLte | int256 and uint256 |
assertContains | address[] , bytes32[] , int256[] , string[] , and uint256[] |
PRBTest can be used alongside all testing utilities from forge-std, except for their Test contract.
// SPDX-License-Identifier: UNLICENSED
pragma solidity >=0.8.0;
import { PRBTest } from "@prb/test/PRBTest.sol";
import { stdError } from "forge-std/Test.sol";
contract MyTest is PRBTest {
function testArithmeticOverflow() external pure {
uint256 a = type(uin256).max;
uint256 b = 1;
vm.expect(stdError.arithmeticError);
a + b;
}
}
DSTest is great. I have myself used it for a while, and I like it a lot. But, with time, I slowly came to realize that there's a lot of room for improvement.
DSTest is incomplete. Some commonly needed assertions, like equality assertions for arrays, assertEq(bool,bool)
and
assertNotEq
, are missing from DSTest. PRBTest fills these gaps, and then some.
Also, the DSTest testing assertions are not themselves tested. Whereas the PRBTest testing assertions are tested, and in fact they are quite thoroughly tested. All other things being equal, this should give you more confidence that your tests do what you intend them to do.
DSTest doesn't version its releases, which makes it difficult to future-proof consumer repos. It's quite easy to to accidentally update your git submodules and thus break your test suites. For some users, this is a real pain.
PRBTest is versioned via tags and branches and all changes are tracked in a CHANGELOG file. I maintain redundant branches for each release because git submodules don't support tags.
I will strive to follow the semver versioning scheme, though I won't do this before the v1.0 release, and it might not always be feasible.
As one of the maintainers of DSTest said here, updating DSTest is painful to orchestrate. The reasons for this are twofold:
So any significant change in DSTest might wreak havoc downstream.
This issue has led to a "balkanization" of DSTest forks and extensions. See, for instance, Solmate's
DSTestPlus and Forge Std's Test. Also see the discussions in this
PR, in which the PR author ended up making the PR against forge-std
rather than ds-test
because he feared that his PR won't be merged in the latter.
It is my firm conviction that Foundry is the future of Ethereum smart contract development. Solidity code is best tested in Solidity itself.
But, due to various historical reasons, the Ethereum ecosystem has for a long time relied upon JavaScript for testing smart contracts. Refactoring a code base from Hardhat or Truffle to Foundry takes time, and it may not always be possible to do it in one fell swoop. Thus, to ensure backwards compatibility, PRBTest is available as a Node.js package in the npm package registry.
For more details about this, see this discussion here.
Feel free to dive in! Open an issue, start a discussion or submit a PR.
You will need the following software on your machine:
In addition, familiarity with Solidity is requisite.
Clone this repository including submodules:
$ git clone --recurse-submodules -j8 git@github.com:paulrberg/prb-test.git
Then, inside the project's directory, run this to install the Node.js dependencies:
$ yarn install
Now you can start making changes.
These contracts were inspired by or directly modified from the following sources:
MIT © Paul Razvan Berg
[0.2.1] - 2022-12-04
FAQs
Modern collection of testing assertions and logging utilities for Solidity
The npm package @prb/test receives a total of 3,010 weekly downloads. As such, @prb/test popularity was classified as popular.
We found that @prb/test demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Solo open source maintainers face burnout and security challenges, with 60% unpaid and 60% considering quitting.
Security News
License exceptions modify the terms of open source licenses, impacting how software can be used, modified, and distributed. Developers should be aware of the legal implications of these exceptions.
Security News
A developer is accusing Tencent of violating the GPL by modifying a Python utility and changing its license to BSD, highlighting the importance of copyleft compliance.