Testing & Debugging

A healthy Relix project treats testing as part of the development loop, not as an afterthought. Because Relix follows the EVM model, you can rely on the same patterns you already use elsewhere: fast local tests, targeted testnet runs, and clear tooling for tracing failures.

This page outlines a practical flow:

1. Prove logic locally.

2. Exercise contracts on Relix Testnet (chain ID 4127).

3. Use logs, traces, and the explorer when things go wrong.

---

1. Local testing first

Before touching the network, keep the feedback loop tight on your machine.

Common approaches:

• Hardhat

  • npx hardhat test for unit and integration tests in JavaScript/TypeScript.

  • hardhat node for a local, in-memory chain where you can deploy and poke contracts quickly.

• Foundry

  • forge test for high-speed tests written in Solidity.

  • forge script for simulating deployments or complex flows before broadcasting them.

Local tests should cover:

• Core contract invariants (supply, access control, math).

• Critical flows (deposits, withdrawals, swaps, mints, burns).

• Failure cases (reverts, permission checks, boundary conditions).

The goal is simple: by the time you reach Relix Testnet, you are validating integration and behavior under network conditions, not fighting basic logic bugs.

---

2. Using Relix Testnet for integration

Once the contract suite behaves locally, move to Relix Testnet:

• Chain ID: 4127

• RPC URL: https://rpc-testnet.relixchain.com

• Explorer: https://testnet.relixchain.com

On testnet, you can exercise:

• Wallet flows (connect, sign, send RLX).

• UI interactions with real RPC latency and gas.

• Cross-contract behavior that may be hard to fully model locally.

A typical pattern:

1. Deploy contracts with Hardhat/Foundry/Remix to Relix Testnet.

2. Note deployed addresses in a small config file (for example deployments.relix.testnet.json).

3. Point your frontend or scripts at these addresses and run through real user flows:

   • Creating positions, placing orders, minting NFTs, etc.

   • Triggering error paths deliberately (invalid inputs, insufficient balance, wrong caller).

Testnet is the place to catch integration issues, misconfigured RPC logic, and assumptions about gas costs or block timing.

---

3. Inspecting transactions and events

When a transaction misbehaves, the explorer is often the fastest source of truth.

On https://testnet.relixchain.com you can:

• Look up a transaction hash and check:

  • Status (success or revert).

  • Gas used and effective gas price.

  • Logs emitted by your contracts.

• Inspect a contract address:

  • Deployment transaction.

  • Recent interactions.

  • Event history.

If your contracts emit rich events (with clear names and indexed fields), debugging becomes far easier:

• Log important state transitions: created, updated, cancelled, withdrawn.

• Include key identifiers as indexed topics: user addresses, order IDs, token addresses.

• Use events as an “audit trail” to reconstruct how a particular state was reached.

For backend or analytics work, you can mirror this with eth_getLogs over the RPC, but the explorer is usually the fastest starting point when diagnosing a specific issue.

---

4. Tracing and revert reasons

When a transaction reverts:

• Check the error message returned to the caller (if your tooling captures it).

• Verify that all require / revert statements have meaningful strings; opaque messages make debugging harder for you and for integrators.

In local environments:

• Hardhat and Foundry both surface revert messages directly in test output.

• You can use Hardhat’s or Foundry’s debugging tools to step through a failing call, inspect variables, and see exactly where execution stops.

On Relix Testnet:

• Libraries such as ethers.js or viem will usually surface the revert data if the RPC node exposes it.

• You can wrap critical calls in dedicated scripts that print decoded error messages and key parameters before, during, and after calls.

Good habits here:

• Avoid silent failures; always revert with context.

• Mirror complex on-chain flows with test scripts that you can run repeatedly against Relix.

---

5. Frontend debugging

For dApps, many “blockchain bugs” start as integration mistakes in the UI:

• Wrong chain ID (not 4127).

• Using the wrong RPC URL or mixing it with another network.

• Passing incorrect types (for example, strings where BigInt is required).

Practical checks:

• Log the active chain ID and RPC in development builds.

• Show clear error messages when the user is on a different network.

• Validate user inputs before sending transactions (addresses, amounts, deadlines).

For React-based frontends, libraries like wagmi or your own hooks can be instrumented to:

• Print raw call parameters in development mode.

• Show links to the Relix explorer whenever a transaction is sent, pending, or confirmed.

This makes it easy to jump from a UI event to the corresponding on-chain trace.

---

6. Common issues and how to approach them

A few recurring problems and how to think about them:

• “Transaction failed” with no obvious reason

  • Re-run the scenario locally with the same parameters in a test.

  • Add temporary logging events around the suspected failure point.

  • Verify balances and allowances carefully.

• “Call works locally but fails on Relix Testnet”

  • Check that contract addresses match the intended deployment on Relix.

  • Confirm that any external dependency (oracle, router, registry) actually exists on Relix Testnet.

  • Look for chain-specific assumptions (hardcoded IDs, fixed gas limits, or block numbers).

• “Frontend says connected, but nothing updates”

  • Confirm that the provider really points to https://rpc-testnet.relixchain.com.

  • Check browser console for CORS/network errors.

  • Verify that the wallet network and the dApp’s assumed network are in sync.

---

7. Build a repeatable debug loop

The most effective teams treat debugging as a repeatable process:

1. Reproduce – capture inputs, accounts, and exact steps.

2. Isolate – move the scenario into a local test or small script.

3. Inspect – use events, logs, and traces to see what actually happened.

4. Fix & verify – write a test that would have caught this bug, and keep it in the suite.

5. Re-run on Relix Testnet – confirm that the bug is gone in a real network environment.

Relix is designed to fit into this kind of workflow: fast local tools for logic, a predictable testnet for integration, and standard EVM interfaces for deep inspection when something goes wrong.