Hello, my name is Heorhii, and in this guide, we’ll explore how to effectively test Leo programs on Aleo. Aleo offers developers various testing approaches that range from local environments to networked test setups. This flexibility enables developers to choose a setup that matches the complexity of their testing requirements, ensuring a robust development workflow. Here’s how you can set up and test Leo programs on Aleo.

1. Local testing without network. Local testing without network interaction provides a straightforward, quick way to validate program logic. This method is especially useful for early-stage testing and debugging without the complexities of network constraints.

Running local tests. To run local tests, navigate to your project directory and execute:

leo run <FUNCTION_ID> <FUNCTION_ARGUMENTS>

This command uses the private key stored in your .env file to simulate the function call, allowing you to quickly test program functionality without network delays or external factors.

Benefits and limitations. Local testing without a network is efficient and provides fast feedback. It effectively tests basic transitions, like record creation and consumption. However, it has limitations:

• No async functions: Since there is no active network, async functions can’t be tested.

• No mapping state or double-spend protections: Without a network to track states, this setup doesn’t enforce mapping states or double-spending checks.

Local testing works well for simple validation but may fall short for more complex cases where you need network-based validations or asynchronous operations.

2. Local testing with network. For a more realistic testing environment, setting up a Local Development Network (Devnet) allows for isolated network interactions and transaction-based testing. This method validates state transitions and ensures record validation.

Setting up a local Devnet. To set up a local devnet, you’ll need tmux to manage multiple nodes and environments.

• macOS: Install via Homebrew:

• Ubuntu: Install with apt:

  sudo apt update
  sudo apt install tmux
  

• Windows: Install via Windows Subsystem for Linux (WSL):

  • Set up WSL from the Microsoft Store or through the command line.

  • Open WSL and run:

    sudo apt update
    sudo apt install tmux
    

https://learn.microsoft.com/en-us/windows/wsl/install

Running the Devnet environment:

1. Clone the snarkOS repository if you haven’t already:

   git clone https://github.com/AleoHQ/snarkOS
   cd snarkOS
   

2. Start the devnet by running:

   ./devnet.sh
   

3. Follow the prompts:

   • Select the number of validators and clients or press Enter for defaults.

   • Set the network ID or use the default.

   • Choose "y" to build binaries (first-time setup), otherwise "n" to skip.

   • Choose "y" to clear ledger history for a clean start, or "n" to retain the previous environment.

4. Navigating Nodes in tmux:

   • Move to the next node: Ctrl+b n

   • Move to the previous node: Ctrl+b p

5. Find the Validator Node 0 and note its private key. This private key is pre-funded with test Aleo Tokens (AT) for devnet testing.

6. Use http://localhost:3030 as the API endpoint for all local devnet interactions.

Deploying and testing on Devnet. With the devnet running, you can:

• Deploy a program:

• Execute transactions:

  leo execute
  

This setup enables a complete testing environment that includes async functions, state transitions, and network-enforced validations like double-spending prevention.

3. Testing with Aleo Testnet. The Aleo Testnet mirrors the mainnet environment closely, making it ideal for production-like testing. Keep in mind that the Testnet assigns unique IDs to each program, so once deployed, you can’t redeploy the same ID.

Setting up Testnet testing. To test on the Aleo Testnet, use REST API calls directed to the following endpoints:

• Public API Endpoint: https://api.explorer.provable.com/v1/testnet

• Private API Endpoints: Some infrastructure providers may offer private testnet endpoints.

https://api.explorer.provable.com/v1/testnet

Refer to the validator node REST API documentation for additional details on available commands.

https://developer.aleo.org/references/apis/latest_height

More info about this here:

https://developer.aleo.org/guides/leo/testing

Summary. Each testing approach has unique benefits suited for different development stages:

1. Local Testing without network

   • Fast and efficient for initial testing

   • Limited to synchronous functions, with no mapping or state persistence

2. Local Testing with network

   • Suitable for comprehensive testing of state transitions and async functions

   • Enables mapping states and double-spending prevention within a sandboxed network

3. Testing with Aleo Testnet

   • Closely mimics mainnet conditions, offering production-grade testing

   • Program redeployment requires unique IDs for each test iteration

With these options, developers can thoroughly test Leo programs at every stage, ensuring secure and reliable functionality on the Aleo network.

When you're ready to mimic production conditions as closely as possible, the Aleo Testnet becomes essential. By closely resembling mainnet behavior, it offers a reliable environment to assess how your program will perform in a live, decentralized network. Since redeploying programs on the Testnet requires unique IDs for each iteration, it encourages thorough preparation, making it a powerful choice for final-stage testing. This layered approach provides flexibility, allowing developers to test for functionality, security, and reliability at every critical stage of development.

Happy coding!

To know more about Aleo, join now!

• Aleo Twitter

• Aleo Discord

• Aleo Website

• List of Aleo and Leo code and resourses

Prepared by Colliseum

Hello, my name is Heorhii, and in this guide, we’ll explore how to effectively test Leo programs on Aleo. Aleo offers developers various testing approaches that range from local environments to networked test setups. This flexibility enables developers to choose a setup that matches the complexity of their testing requirements, ensuring a robust development workflow. Here’s how you can set up and test Leo programs on Aleo.

1. Local testing without network. Local testing without network interaction provides a straightforward, quick way to validate program logic. This method is especially useful for early-stage testing and debugging without the complexities of network constraints.

Running local tests. To run local tests, navigate to your project directory and execute:

leo run <FUNCTION_ID> <FUNCTION_ARGUMENTS>

This command uses the private key stored in your .env file to simulate the function call, allowing you to quickly test program functionality without network delays or external factors.

Benefits and limitations. Local testing without a network is efficient and provides fast feedback. It effectively tests basic transitions, like record creation and consumption. However, it has limitations:

• No async functions: Since there is no active network, async functions can’t be tested.

• No mapping state or double-spend protections: Without a network to track states, this setup doesn’t enforce mapping states or double-spending checks.

Local testing works well for simple validation but may fall short for more complex cases where you need network-based validations or asynchronous operations.

2. Local testing with network. For a more realistic testing environment, setting up a Local Development Network (Devnet) allows for isolated network interactions and transaction-based testing. This method validates state transitions and ensures record validation.

Setting up a local Devnet. To set up a local devnet, you’ll need tmux to manage multiple nodes and environments.

• macOS: Install via Homebrew:

• Ubuntu: Install with apt:

  sudo apt update
  sudo apt install tmux
  

• Windows: Install via Windows Subsystem for Linux (WSL):

  • Set up WSL from the Microsoft Store or through the command line.

  • Open WSL and run:

    sudo apt update
    sudo apt install tmux
    

https://learn.microsoft.com/en-us/windows/wsl/install

Running the Devnet environment:

1. Clone the snarkOS repository if you haven’t already:

   git clone https://github.com/AleoHQ/snarkOS
   cd snarkOS
   

2. Start the devnet by running:

   ./devnet.sh
   

3. Follow the prompts:

   • Select the number of validators and clients or press Enter for defaults.

   • Set the network ID or use the default.

   • Choose "y" to build binaries (first-time setup), otherwise "n" to skip.

   • Choose "y" to clear ledger history for a clean start, or "n" to retain the previous environment.

4. Navigating Nodes in tmux:

   • Move to the next node: Ctrl+b n

   • Move to the previous node: Ctrl+b p

5. Find the Validator Node 0 and note its private key. This private key is pre-funded with test Aleo Tokens (AT) for devnet testing.

6. Use http://localhost:3030 as the API endpoint for all local devnet interactions.

Deploying and testing on Devnet. With the devnet running, you can:

• Deploy a program:

• Execute transactions:

  leo execute
  

This setup enables a complete testing environment that includes async functions, state transitions, and network-enforced validations like double-spending prevention.

3. Testing with Aleo Testnet. The Aleo Testnet mirrors the mainnet environment closely, making it ideal for production-like testing. Keep in mind that the Testnet assigns unique IDs to each program, so once deployed, you can’t redeploy the same ID.

Setting up Testnet testing. To test on the Aleo Testnet, use REST API calls directed to the following endpoints:

• Public API Endpoint: https://api.explorer.provable.com/v1/testnet

• Private API Endpoints: Some infrastructure providers may offer private testnet endpoints.

https://api.explorer.provable.com/v1/testnet

Refer to the validator node REST API documentation for additional details on available commands.

https://developer.aleo.org/references/apis/latest_height

More info about this here:

https://developer.aleo.org/guides/leo/testing

Summary. Each testing approach has unique benefits suited for different development stages:

1. Local Testing without network

   • Fast and efficient for initial testing

   • Limited to synchronous functions, with no mapping or state persistence

2. Local Testing with network

   • Suitable for comprehensive testing of state transitions and async functions

   • Enables mapping states and double-spending prevention within a sandboxed network

3. Testing with Aleo Testnet

   • Closely mimics mainnet conditions, offering production-grade testing

   • Program redeployment requires unique IDs for each test iteration

With these options, developers can thoroughly test Leo programs at every stage, ensuring secure and reliable functionality on the Aleo network.

When you're ready to mimic production conditions as closely as possible, the Aleo Testnet becomes essential. By closely resembling mainnet behavior, it offers a reliable environment to assess how your program will perform in a live, decentralized network. Since redeploying programs on the Testnet requires unique IDs for each iteration, it encourages thorough preparation, making it a powerful choice for final-stage testing. This layered approach provides flexibility, allowing developers to test for functionality, security, and reliability at every critical stage of development.

Happy coding!

To know more about Aleo, join now!

• Aleo Twitter

• Aleo Discord

• Aleo Website

• List of Aleo and Leo code and resourses

Prepared by Colliseum