Skip to main content

Testing modes and networks

Before putting new software in production, as a developer or baker, you need to test it in environments where trying and breaking things doesn't cost much, in terms of time, computing resources or even fees.

A number of possibilities are made available thanks to tools and services provided by the Tezos ecosystem. In this document, we will briefly introduce them, present their specificities, and what use cases they are suitable for.

Testing without a node​

If you are a smart contract developer, testing contracts is a big part of your work. More time is spent testing contracts than writing them. You will often need to test new versions of your contracts, and run many tests starting from their deployment to calling every entry point in all kinds of ways.

Waiting for the next block every time you inject a new transaction takes a lot of time.

To make testing a lot faster, options are available, depending on the language and tools you are using, that don't use a network or even a single node at all, and skip all the consensus mechanism steps.

  • The michelson interpreter is an OCaml function that can be used by tools to simulate a call to any entry point of any smart contract, given an initial value of the storage and parameters. Some programming languages like Ligo or Smartpy use this as part of their testing frameworks.

  • The mockup mode of octez-client can be used to test contract calls and other features such as some RPC calls, all without running an actual node, saving the time of going through the consensus mechanism and waiting to get blocks created and validated. Tools like Completium, built by the team behind the Archetype language, use this for their testing framework. Find out more in the documentation of the mockup mode.

Testing with local nodes​

The sandboxed mode of octez-client makes it possible to test your contracts or other projects while interacting with actual nodes, but without using a public test network or creating your own private network. In sandboxed mode, octez-client can create one or more local nodes for this.

This is convenient if you want to run all your tests locally but in a mode where blocks are actually created through the consensus mechanism. In particular, if your contracts or tests must stay confidential until you decide to put them into production.

In this mode, you can't use public services such as public block explorers or indexers. You may, however, install your own.

One of the fastest ways to run a sandbox network is to use Docker. The Flextesa Docker image allows you to set up a sandbox quickly with the protocol of your choice and pre-funded accounts.

Find out more in the documentation of the sandboxed mode.

Testing with public test networks​

If you want to test your development in conditions closer to those of Tezos Mainnet, you can use one of a number of public test networks.

These behave like Mainnet, with a few differences:

  • You can use faucets to obtain tez for free on these networks, so you don't need to (and can't) spend actual tez.
  • They use different constants than Mainnet, for example reduced block times and shorter cycles for faster testing, reduced windows for inserting rejections in rollups, etc.
  • Tools like public block explorers or indexers may or may not be available, depending on the network.
  • They either use a modified version of the amendment process (Ghostnet) or don't use it at all.
  • Different test networks run on different versions of the protocol.

Depending on your needs, you may pick between the three types of networks listed below. The different test networks provide different foresight into the changes brought by upcoming protocol amendments -- from a week to 6 months, under the current policy of rolling protocol proposal publication.

In all cases, if you need to do intense testing, we recommend that you run your own nodes on these networks, as public nodes may have availability issues and limitations.

Permanent test networks​

Permanent test networks are networks that are meant to run indefinitely. In particular, they migrate to new versions of the protocol when proposals are adopted.

For the Ghostnet permanent network, the governance is controlled by a single entity that manages the network, with a special upgrade mechanism.

At the moment, the main such network is Ghostnet. It follows the currently active protocol on Mainnet, and upgrades to the next protocol during the Adoption period on Mainnet. That is, after the last round of voting and before it activates on Mainnet. The objective is to provide a dress rehearsal event for Mainnet migration.

For developers, using a permanent network like Ghostnet is convenient compared to other public networks, as it makes it possible to keep contracts running for a long time, and not having to deal with the trouble of setting things up on a new network when the previous ones get shut down. Services such as indexers, explorers or public nodes also tend to keep running more reliably on Ghostnet than on non-permanent networks.

For bakers, it is also a good idea to run tests on a permanent network, as it is the environment that is the closest to Mainnet. Ghostnet, in particular, can be used as a staging environment for testing new set-ups, or new versions of software, for example new Octez releases.

On the other hand, as transactions and blocks keep accumulating over time, synchronizing with this network can take some time, and the context size gets bigger. This means testing a restart and resynchronization can be time and resource consuming.

As the protocol on Ghostnet migrates to the newly adopted amendment a few days before Mainnet, during the Adoption period, it can serve as a dress-rehersal for the actual migration on Mainnet. Both bakers and developers can check that they are ready for the migration, and that nothing in their configuration breaks when it happens.

Protocol test networks​

Protocol test networks are networks that are created specifically for a given version of the protocol.

When an amendment is proposed, a corresponding network is usually created. This network gets joined by more bakers as the proposal is selected and moves through the different periods of the self-amendment process. If the protocol passes the 3 votes of the amendment, joining a test protocol early gives you about 2.5 months to test all the changes that will be made to Mainnet. If the protocol is not adopted, it usually gets discarded. Otherwise, it remains active until a different protocol is adopted.

This means there is usually one or two such running networks: one for the current version of the protocol running on Mainnet, and possibly one for the proposed protocol that is going through the amendment process, if there is one.

Whether you are a developer or a baker, testing on the network for a new proposal before it potentially gets activated, enables you to check that all your software, smart contracts, dApps or other tools work well with this new proposal.

It also enables you to test any new features of this proposal, so that you can prepare to use them. This can also help you form your own opinion about this proposal and discuss it with the community before voting on it.

Once the protocol is activated, the corresponding protocol test network can be a good network for a baker to do some tests, with the current version of the protocol, and doing so on a network that is lightweight to bootstrap, and with reduced context sizes.

On the other hand, it may be less convenient for smart contract or dApps developers to use, as it has a limited life span, and tends to be less supported by services like indexers and other tools.

Periodic test networks​

Periodic test networks target developers, and in particular infrastructure and core developer teams. Their purpose is to test new features as they are being developed and before they are even part of a new proposal.

Periodic testnets are based on Alpha development versions of the Tezos Economic Protocol and the Octez suite.

Such networks have a very short life span: new ones are regularly created under similar names as changes are made to the protocol and the previous ones then quickly disappear.

Testing on such networks is useful for developers that need to test the latest features early and prepare for tools that need to be ready early to support them.

The only periodic protocol currently is Weeklynet, which is a network that restarts every Wednesday, with the latest Docker build as reference. It is the place to test upcoming new features, such as the SCORUs currently. It is also a network to use if you are a big baker, or a BaaS provider and you want to test tailored infrastructure.

Public nodes and faucets​

To connect to existing public nodes for these networks, or to get some tesnet-only tez on these from a faucet, check https://teztnets.com.

Other sources of public nodes include:

Testing with your own private network​

In some special cases, you may want to run your own private network for your testing. This could be true if you are developing tools that you want to keep confidential until you put them in production, and if the sandboxed mode is not sufficient for your situation.

Check out Private blockchain section to learn how to set up your own network.

Further reading​