Skip to main content

Testing Smart Contracts

Testing is an essential part of smart contract development to ensure the correctness and reliability of your code. The Cadence Testing Framework provides a convenient way to write tests for your contracts, scripts and transactions which allows you to verify the functionality and correctness of your smart contracts.

Install Flow CLI​

The Flow CLI is the primary tool for developing, testing, and deploying smart contracts to the Flow network.

If you haven't installed the Flow CLI yet and have homebrew installed, simply run brew install flow-cli. Alternatively, refer to the Flow CLI installation instructions.

Create a new project​

In your preferred code editor, create a new directory for your project and navigate to it in the terminal. Then initialize a new Flow project by running the command flow init. This will create a flow.json config file that contains the project's configuration.


_10
mkdir test-cadence
_10
cd test-cadence
_10
flow init

Write a simple smart contract​

In your code editor, create a new file called calculator.cdc and add the following code:

calculator.cdc

_16
access(all) contract Calculator {
_16
access(all)
_16
fun add(a: Int, b: Int): Int {
_16
return a + b
_16
}
_16
_16
access(all)
_16
fun subtract(a: Int, b: Int): Int {
_16
return a - b
_16
}
_16
_16
access(all)
_16
fun multiply(a: Int, b: Int): Int {
_16
return a * b
_16
}
_16
}

Add the smart contract to the config​

Next up, we need to add our new contract in the contracts key in the flow.json config file. More specifically, we need to add the contract name, location and an address alias for the testing environment.


_13
{
_13
"contracts": {
_13
"Calculator": {
_13
"source": "./calculator.cdc",
_13
"aliases": {
_13
"testing": "0x0000000000000007"
_13
}
_13
}
_13
},
_13
"networks": {...},
_13
"accounts": {...},
_13
"deployments": {...}
_13
}

For the time being, the address for the testing alias, can be one of:

  • 0x0000000000000005
  • 0x0000000000000006
  • 0x0000000000000007
  • 0x0000000000000008
  • 0x0000000000000009
  • 0x000000000000000a
  • 0x000000000000000b
  • 0x000000000000000c
  • 0x000000000000000d
  • 0x000000000000000e

In the next release, there will be 20 addresses for contract deployment during testing.

Write unit tests​

In the same directory, create a new file called calculator_test.cdc and add the following code:

calculator_test.cdc

_22
import Test
_22
import "Calculator" // contract name from the previous step
_22
_22
access(all)
_22
fun setup() {
_22
let err = Test.deployContract(
_22
name: "Calculator",
_22
path: "./calculator.cdc",
_22
arguments: []
_22
)
_22
Test.expect(err, Test.beNil())
_22
}
_22
_22
access(all)
_22
fun testAdd() {
_22
Test.assertEqual(5, Calculator.add(a: 2, b: 3))
_22
}
_22
_22
access(all)
_22
fun testSubtract() {
_22
Test.assertEqual(2, Calculator.subtract(a: 5, b: 3))
_22
}

This code:

  • imports the Calculator contract from the calculator.cdc file (according to flow.json)
  • deploys the Calculator contract to the address specified in the testing alias
  • defines two test cases: testAdd() and testSubtract()
  • calls add() and subtract() methods with different input values respectively.

Running the test cases​

To run the test cases, use the following command in the terminal:


_10
flow test --cover --covercode="contracts" calculator_test.cdc

This command uses the Flow CLI to run the test cases and display the output. You should see the following output:


_10
Test results: "calculator_test.cdc"
_10
- PASS: testAdd
_10
- PASS: testSubtract
_10
Coverage: 66.7% of statements

This output indicates that both test cases ran successfully, and the two smart contract methods are functioning as expected. With the supplied flags (--cover & --covercode="contracts"), we also get code coverage insights for the contracts under testing. The code coverage percentage is 66.7%, because we have not added a test case for the multiply method. By viewing the auto-generated coverage.json file, we see:


_14
{
_14
"coverage": {
_14
"A.0000000000000007.Calculator": {
_14
"line_hits": {
_14
"14": 0,
_14
"4": 1,
_14
"9": 1
_14
},
_14
"missed_lines": [14],
_14
"statements": 3,
_14
"percentage": "66.7%"
_14
}
_14
}
_14
}

Line 14 from the Calculator smart contract is marked as missed. This is the line:


_10
return a * b

which is the multiply method.

By adding a test case for the above method:

calculator_test.cdc

_10
...
_10
_10
access(all)
_10
fun testMultiply() {
_10
Test.assertEqual(10, Calculator.multiply(a: 2, b: 5))
_10
}

our code coverage percentage goes to 100%:


_10
flow test --cover --covercode="contracts" calculator_test.cdc
_10
_10
Test results: "calculator_test.cdc"
_10
- PASS: testAdd
_10
- PASS: testSubtract
_10
- PASS: testMultiply
_10
Coverage: 100.0% of statements

Advanced Testing Techniques​

The Cadence testing framework provides various features and techniques for writing comprehensive test scenarios. Some of these include:

  • Code Coverage: You can use the --cover flag with the flow test command to view code coverage results when running your tests. This allows you to identify areas of your code that are not adequately covered by your test inputs.
  • Test Helpers: Test helpers are reusable functions that help you set up the initial state for your test files. You can define test helpers in a Cadence program and use them in your test files by importing it whenever needed.
  • Assertions: The testing framework provides built-in assertion functions, such as assertEqual, beNil, beEmpty, contain, to help you verify the expected behavior of your smart contracts.
  • Test Suites: You can organize your test files into test suites to improve the readability and maintainability of your test code. Test suites allow you to group related test cases and set up common test helpers for all the tests in the suite.
  • Integration tests: In our previous example, we would directly call the available methods on the contract under test. This is generally categorized as unit testing. You can also write integration tests, by executing scripts & transactions to interact with the contracts under testing. If you would like to write your tests in Go, instead of Cadence, you can use Overflow tool to run integration tests against either an local emulator, testnet, mainnet or an in memory instance of the flow-emulator.

By leveraging these advanced testing techniques, you can write more robust and reliable smart contracts in Cadence. In this example, we set up a basic testing environment, wrote a simple smart contract in Cadence, and created a test file to verify its functionality. We then used the Flow CLI to run the test file and confirm that the smart contract is working correctly.

This is a basic example, and there are many more advanced features and techniques you can explore when working with the Cadence Testing Framework.

For more in-depth tutorials and documentation, refer to the official Cadence language documentation and the Flow CLI documentation.

Testing Requirements​

It is suggested to follow the following best practices:

  • Every publicly exposed feature of a contract and its resources should have unit tests that check both for success with correct input and for failure with incorrect input. These tests should be capable of being run locally with the Flow emulator, with no or minimal extra resources or configuration, and with a single command.
  • Each user story or workflow that uses the smart contracts should have an integration test that ensures that the series of steps required to complete it does so successfully with test data.

Make sure you test all contracts - and the integration into your application extensively before proceeding to the mainnet. You should aim to replicate all conditions as closely as possible to the usage patterns on mainnet.

Writing Tests​

There are official SDKs/frameworks for Flow in Cadence, Go and JavaScript.

In all three cases, the test code will need to deploy the contracts, configure accounts to interact with them and send transactions to them. It will then have to wait for the transactions to be sealed and check the results by catching exceptions, checking for events, and querying state using scripts.

Cadence tests​

Cadence comes with built-in support for code coverage, as well as a native testing framework which allows developers to write their tests using Cadence. This framework is bundled with the Flow CLI tool, which includes a dedicated command for running tests (flow test).

You can find examples of Cadence tests in the following projects: hybrid-custody, flow-nft, flow-ft. Visit the documentation to view all the available features.

The Hybrid Custody project is a prime example which utilizes both the Cadence testing framework and code coverage in its CI.

Hybrid Custody CI

There is also a repository which contains some sample contracts and their tests.

Automated CI Coverage Report

Coverage Report Visualization

info

The Cadence testing framework utilizes the emulator under the hood.

Fork Testing​

Fork testing lets you run your Cadence test files (*_test.cdc) against a snapshot of a live Flow network (mainnet or testnet). This enables realistic integration tests that read real contract code and on-chain state while keeping all mutations local to your test run.

info

This section covers flow test --fork (running tests against a forked network), which is different from flow emulator --fork (starting the emulator in fork mode for manual interaction).

What is fork testing?​

When you run tests with the --fork flag, the test runner:

  • Connects to a Flow access node (public or custom)
  • Fetches account state, contract code, and other data on demand
  • Executes your tests as if they are running against the live network state
  • Keeps all state changes local to your test process (the real network is never mutated)

This bridges the gap between fast, purely local tests and deploying to testnet/mainnet for validation.

Quick start​

Example: Read from the real FlowToken contract on mainnet.

flow_token_test.cdc

_10
import Test
_10
import "FlowToken" // Resolves to mainnet alias when running with --fork
_10
_10
access(all) fun testFlowTokenSupplyIsPositive() {
_10
let supply = FlowToken.totalSupply
_10
Test.assert(supply > 0.0, message: "FlowToken supply should be positive")
_10
}

Ensure your flow.json defines the mainnet alias for FlowToken:


_15
{
_15
"contracts": {
_15
"FlowToken": {
_15
"source": "./cadence/contracts/FlowToken.cdc",
_15
"aliases": {
_15
"mainnet": "0x1654653399040a61"
_15
}
_15
}
_15
},
_15
"networks": {
_15
"mainnet": {
_15
"host": "access.mainnet.nodes.onflow.org:9000"
_15
}
_15
}
_15
}

Run the test against a fork of mainnet:


_10
flow test --fork

To target testnet instead:


_10
flow test --fork testnet

Common use cases​

  • Integration testing with real contracts (NFT marketplaces, DEXs, core contracts)
  • Pre-deployment validation against production data
  • Upgrade testing with production state
  • Historical debugging with a specific block height

Examples:


_10
# Run a single test file against mainnet
_10
flow test tests/my_marketplace_test.cdc --fork mainnet
_10
_10
# Pin to a specific block height for historical state
_10
flow test --fork mainnet --fork-height 85432100
_10
_10
# Generate coverage while forking
_10
flow test --fork --cover

How contract aliases are resolved​

  • Normal mode (no --fork): your imports use the testing aliases from flow.json (for emulator deployments)
  • Fork mode: imports automatically use the aliases for the selected network (e.g. mainnet or testnet) defined in flow.json

This means you typically do not need to change imports in your test code when switching between local and forked runs—configure aliases once and select the mode via flags.

Limitations and considerations​

  • Network performance: tests may run slower than local emulator tests due to network calls
  • Point-in-time snapshot: forked state reflects the time of query (or the specified --fork-height), not a live stream
  • Read-only network: mutations in your tests are local and do not affect the real network
  • Spork boundaries: access nodes only retain historical data for the current spork; pinning via --fork-height cannot reach beyond that boundary. Learn more about the Flow spork process in the Network Upgrade (Spork) docs.

See: Network Upgrade (Spork) Process

Best practices​

  1. Use fork testing primarily for integration tests; keep unit tests on the emulator for speed
  2. Keep forked tests separate in CI and run them selectively
  3. Prefer testnet before mainnet to catch network-specific issues with fewer risks
  4. Document dependencies on specific mainnet/testnet contracts and addresses
  5. Consider real data requirements—fork testing shines when reading existing on-chain state

Commands reference​

See the flag reference for available options and details.

Guide → Tutorial: Fork Testing with Cadence (Step-by-Step)

Guide → Flags: Fork Testing Flags


_10
flow test --fork # Fork from mainnet (default when value omitted)
_10
flow test --fork testnet # Fork from testnet
_10
flow test --fork --cover # With coverage report
_10
flow test --fork --fork-height NUM # Pin to block height

Go Tests​

Tests in Go can be written using flow-go-sdk and the go test command.

You can find examples of Go tests in the following projects: flow-core-contracts, flow-nft, flow-ft.

info

These tests are tied to the emulator but can be refactored to run on testnet

Testing Your Application​

Automated Testing of Contract Code​

All contracts should include test coverage for all contract functions. Make sure you've accounted for success and failure cases appropriately.

Tests should also be runnable in automated environments (CI). You can use the Cadence testing utils to create tests for your smart contract code.

Stress Testing Live Applications Before Mainnet​

Once you deployed your application to the testnet, you should record how your application handles non-trivial amounts of traffic to ensure there are no issues.

tip

Get familiar with the Cadence anti-patterns to avoid avoid problematic or unintended behavior.

References​

Rate this page