Antes de desplegar un smart contract en mainnet o ejecutar una transacción que involucre fondos reales, todo equipo DevOps necesita un entorno donde probar de forma segura. Las redes de prueba (testnets) y las redes de desarrollo local (devnets) cumplen exactamente esa función: replican el comportamiento de la red principal sin poner en riesgo activos reales. En esta guía cubrimos las testnets mas relevantes del ecosistema Ethereum, las herramientas para desarrollo local, estrategias de testing y como integrar todo en pipelines de CI/CD.

Que son las testnets y por que importan

Una testnet es una red blockchain independiente que utiliza el mismo protocolo que la red principal (mainnet) pero opera con tokens sin valor economico real. Su propósito es permitir a desarrolladores y operadores:

  • Desplegar y probar smart contracts antes de la puesta en producción.
  • Validar cambios en la infraestructura de nodos sin consecuencias financieras.
  • Experimentar con nuevas versiones de clientes de ejecución y consenso.
  • Realizar pruebas de carga y estres sobre la red.
  • Entrenar a equipos en operaciones blockchain sin riesgo.

La diferencia fundamental con mainnet es que los tokens de testnet no tienen valor de mercado. Se obtienen gratuitamente a traves de faucets y el único coste es el tiempo y los recursos computacionales necesarios para operar nodos en estas redes.

Testnets publicas de Ethereum

Despues de la transición a Proof of Stake (The Merge), el ecosistema de testnets de Ethereum se reorganizo. Las redes de prueba activas actualmente son:

Sepolia

Sepolia es la testnet recomendada para desarrollo de aplicaciones y smart contracts. Sus caracteristicas principales:

  • Conjunto de validadores controlado: Opera con un set de validadores permisionados, lo que la hace mas estable y predecible que redes abiertas.
  • Tiempo de bloque: Aproximadamente 12 segundos, identico a mainnet.
  • Soporte amplio: Todos los clientes principales de Ethereum la soportan.
  • Faucets disponibles: Existen multiples faucets como el de Alchemy, Infura y el propio de Sepolia.

Sepolia es ideal para probar despliegues de dApps, interacciones con contratos y flujos de usuario completos.

Holesky

Holesky es la testnet diseñada específicamente para pruebas de infraestructura de staking y validadores:

  • Red abierta de validadores: Cualquiera puede ejecutar un validador, lo que permite probar toda la infraestructura de staking.
  • Gran cantidad de ETH de prueba: Distribuye cantidades significativas de ETH para facilitar pruebas de staking.
  • Escala realista: Disenada para operar con una cantidad de validadores comparable a mainnet.

Si tu trabajo involucra operar validadores, probar configuraciones de clientes de consenso o evaluar infraestructura de staking, Holesky es la red indicada.

Redes de desarrollo local (devnets)

Para desarrollo iterativo rápido, las testnets publicas tienen una limitación: dependen de la red y sus tiempos de bloque. Las devnets locales eliminan esa dependencia.

Hardhat Network

Hardhat es uno de los frameworks de desarrollo mas populares para Ethereum. Su red local integrada ofrece:

// hardhat.config.js
module.exports = {
  networks: {
    hardhat: {
      chainId: 31337,
      mining: {
        auto: true,        // Mina un bloque por cada transaccion
        interval: 0         // Sin delay entre bloques
      },
      accounts: {
        count: 20,
        accountsBalance: "10000000000000000000000" // 10000 ETH
      }
    }
  }
};

Ventajas de Hardhat Network:

  • Minado instantaneo: Cada transacción genera un bloque inmediatamente.
  • Forking de mainnet: Permite hacer fork del estado real de mainnet para pruebas con datos reales.
  • Console.log en Solidity: Facilita enormemente el debugging de smart contracts.
  • Trazas detalladas: Muestra stack traces completos cuando una transacción falla.

Anvil (Foundry)

Anvil es la devnet local del framework Foundry, escrito en Rust, conocido por su velocidad:

# Iniciar Anvil con configuracion personalizada
anvil \
  --fork-url https://eth-mainnet.alchemyapi.io/v2/TU_API_KEY \
  --fork-block-number 18000000 \
  --block-time 12 \
  --accounts 10 \
  --balance 10000 \
  --port 8545

# Anvil expone un endpoint RPC compatible con cualquier herramienta Ethereum

Anvil destaca por:

  • Rendimiento superior: Significativamente mas rápido que alternativas en JavaScript.
  • Compatibilidad total con cheatcodes: Permite manipular el estado de la EVM para testing avanzado.
  • Fork preciso: Soporta fork desde cualquier bloque de mainnet o testnets.

Ganache

Ganache fue una de las primeras herramientas de desarrollo local para Ethereum. Aunque su desarrollo ha sido descontinuado en favor de Hardhat y Foundry, sigue siendo utilizado en proyectos legacy:

# Iniciar Ganache CLI
ganache --port 8545 --networkId 1337 --accounts 10 --defaultBalanceEther 100

Para proyectos nuevos, se recomienda migrar a Hardhat Network o Anvil.

Faucets: obtención de tokens de prueba

Para interactuar con testnets publicas se necesitan tokens de prueba. Los faucets mas confiables incluyen:

  • Alchemy Sepolia Faucet: Requiere cuenta de Alchemy, distribuye Sepolia ETH.
  • Infura Sepolia Faucet: Integrado con el dashboard de Infura.
  • Google Cloud Web3 Faucet: Disponible para Sepolia y Holesky.
  • PoW Faucet: Algunos faucets requieren resolver un pequeño Proof of Work para evitar abuso.

Es comun que los faucets limiten la cantidad de ETH por solicitud y por período de tiempo. Para pruebas intensivas, conviene combinar multiples faucets o utilizar devnets locales.

Diferencias clave entre testnet y mainnet

Aunque las testnets replican el comportamiento de mainnet, existen diferencias importantes que todo equipo DevOps debe considerar:

AspectoMainnetTestnet
Valor de tokensRealNinguno
ValidadoresMiles, distribuidos globalmenteLimitados o controlados
EstabilidadAltaVariable (pueden reiniciarse)
Gas pricesFluctuantes segun demandaGeneralmente bajos y estables
Datos historicosCompletos desde genesisPueden ser reseteados
Disponibilidad de RPCAlta, multiples proveedoresMenor, posibles interrupciones

Un error comun es asumir que si algo funciona en testnet, funcionara identicamente en mainnet. Las condiciones de red, la competencia por espacio de bloque y el comportamiento de MEV son fundamentalmente diferentes.

Estrategias de testing para blockchain

Un enfoque robusto de testing para proyectos blockchain combina multiples niveles:

Tests unitarios

Verifican funciones individuales de smart contracts de forma aislada:

// test/Token.test.js (Hardhat + ethers.js)
describe("Token", function () {
  it("debe asignar el supply total al deployer", async function () {
    const [owner] = await ethers.getSigners();
    const Token = await ethers.getContractFactory("Token");
    const token = await Token.deploy(1000000);

    expect(await token.balanceOf(owner.address)).to.equal(1000000);
  });
});

Tests de integración

Verifican la interacción entre multiples contratos y componentes:

describe("DEX Integration", function () {
  it("debe completar un swap entre dos tokens", async function () {
    // Deploy de tokens y pool de liquidez
    const tokenA = await deployToken("TokenA", 1000000);
    const tokenB = await deployToken("TokenB", 1000000);
    const dex = await deployDEX(tokenA.address, tokenB.address);

    // Aprobar y ejecutar swap
    await tokenA.approve(dex.address, 1000);
    await dex.swap(tokenA.address, tokenB.address, 1000);

    // Verificar balances resultantes
    expect(await tokenA.balanceOf(dex.address)).to.equal(1000);
  });
});

Tests en fork de mainnet

Permiten probar contra el estado real de la red:

# Ejecutar tests contra un fork de mainnet
npx hardhat test --fork https://eth-mainnet.alchemyapi.io/v2/TU_KEY

Tests en testnet pública

Validan el comportamiento en una red real con latencia y condiciones de red reales.

Integración con CI/CD

La integración de testing blockchain en pipelines de CI/CD es fundamental para equipos profesionales:

# .github/workflows/blockchain-tests.yml
name: Blockchain Tests
on: [push, pull_request]

jobs:
  unit-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Instalar dependencias
        run: npm ci

      - name: Compilar contratos
        run: npx hardhat compile

      - name: Tests unitarios (red local)
        run: npx hardhat test

      - name: Tests con fork de mainnet
        run: npx hardhat test --network hardhat
        env:
          FORK_URL: ${{ secrets.ALCHEMY_MAINNET_URL }}

  testnet-deploy:
    needs: unit-tests
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Instalar dependencias
        run: npm ci

      - name: Deploy a Sepolia
        run: npx hardhat run scripts/deploy.js --network sepolia
        env:
          SEPOLIA_RPC_URL: ${{ secrets.SEPOLIA_RPC_URL }}
          DEPLOYER_PRIVATE_KEY: ${{ secrets.DEPLOYER_PRIVATE_KEY }}

      - name: Verificar contrato en Etherscan
        run: npx hardhat verify --network sepolia ${{ env.CONTRACT_ADDRESS }}

Este pipeline ejecuta tests unitarios en una red local (rápido y sin dependencias externas), luego tests con fork de mainnet para validar interacciones reales, y finalmente despliega a Sepolia solo cuando el código llega a la rama principal.

Mejores prácticas DevOps para testnets

  • Separar claramente los entornos: Mantener configuraciones independientes para devnet local, testnet y mainnet. Nunca reutilizar claves privadas entre entornos.
  • Automatizar la obtención de fondos: Crear scripts que soliciten ETH de faucets automáticamente cuando los balances sean bajos.
  • Monitorear las testnets: Aunque sean redes de prueba, monitorear la salud de los nodos y la conectividad evita sorpresas.
  • Documentar las diferencias: Mantener un registro de las divergencias conocidas entre testnet y mainnet.
  • Rotar testnets: Estar preparado para migrar si una testnet es descontinuada, como ocurrio con Ropsten y Rinkeby.

Conclusion

Las redes de prueba son una pieza fundamental en el ciclo de desarrollo blockchain. Desde las devnets locales como Hardhat Network y Anvil para iteración rápida, hasta las testnets publicas como Sepolia y Holesky para validación en condiciones reales, cada herramienta cumple un rol específico. La integración de estas redes en pipelines de CI/CD permite a los equipos DevOps mantener la calidad y seguridad del código antes de interactuar con mainnet, donde los errores tienen consecuencias economicas reales.

Recursos