La Guía Definitiva para Probar Contratos Inteligentes en Stellar

Las pruebas automatizadas son una de las herramientas más poderosas para crear software más confiable y seguro.

Buenas pruebas:

• Confirman que el software hace lo que se pretendía la primera vez que se construyó;
• Proporcionan confianza para refactorizar el código sabiendo que la funcionalidad no ha cambiado;
• Ayudan a los desarrolladores a entender y probar el alcance de un cambio;
• Son un multiplicador en los equipos porque dan a otros la confianza para cambiar código con el que no tienen experiencia previa.

Buenas herramientas y estrategias de prueba hacen nuestro escepticismo mucho más riguroso de lo que solos somos capaces.

Las pruebas unitarias son pruebas pequeñas que prueban una pieza de funcionalidad dentro de un contrato. Son un gran lugar para comenzar y en muchos ecosistemas, son la prueba más simple de escribir. Las pruebas unitarias son útiles cuando el código a probar es una parte estrecha del programa sin pocas o ninguna dependencia.

A continuación se muestra un ejemplo de una prueba unitaria que prueba la funcionalidad de un contrato de incremento.

#![cfg(test)]
use soroban_sdk::Env;
use crate::{IncrementContract, IncrementContractClient};

#[test]
fn test() {
   let env = Env::default();
   let contract_id = env.register(IncrementContract, ());
   let client = IncrementContractClient::new(&env, &contract_id);

   assert_eq!(client.increment(), 1);
   assert_eq!(client.increment(), 2);
   assert_eq!(client.increment(), 3);
}

Para saber más sobre el ejemplo anterior y escribir pruebas unitarias, consulta la guía práctica sobre Pruebas Unitarias.

Las pruebas de integración que prueban con contratos de Mainnet también pueden incorporar datos de Mainnet para que la prueba de integración sea lo más similar posible a una transacción enviada a Mainnet.

Para realizar pruebas de integración contra contratos y sus datos de Mainnet o Testnet, usa el stellar-cli para tomar una instantánea del contrato y sus datos, luego carga esa instantánea en la prueba.

$ stellar snapshot create --address C... --output json --out snapshot.json

A continuación se muestra un ejemplo de una prueba de integración que prueba la funcionalidad de un contrato de incremento junto con una dependencia, el contrato de pausa que se capturó junto con sus datos y se cargó en el entorno en la prueba.

use soroban_sdk::Env;
use crate::{IncrementContract, IncrementContractClient};

#[test]
fn test() {
   let env = Env::from_ledger_snapshot_file("snapshot.json");

   let pause_id = Address::from_str(&env, "C...");
   let contract_id = env.register(
       IncrementContract,
       IncrementContractArgs::__constructor(&pause_id),
   );
   let client = IncrementContractClient::new(&env, &contract_id);

   assert_eq!(client.increment(), 1);
}

Las pruebas diferenciales son las pruebas de dos cosas para descubrir diferencias en su comportamiento. El objetivo es demostrar que las dos cosas se comportan de manera consistente y que no divergen en comportamiento.

Esta estrategia es efectiva al construir algo nuevo que debería comportarse como algo que ya existe. Eso podría ser una nueva versión de un contrato, o podría ser el mismo contrato construido con una nueva versión de un SDK u otra dependencia, o podría ser una refactorización que no espera cambios funcionales.

Cuando realices pruebas diferenciales contra un contrato desplegado, usa el stellar-cli para obtener el contrato de Mainnet o Testnet.

$ stellar contract fetch --id C... –-out-file pause.wasm

A continuación se muestra un ejemplo de una prueba diferencial que prueba que una versión desplegada de un contrato y una nueva versión del contrato se comportan igual y emiten los mismos eventos.

#![cfg(test)]
use crate::{IncrementContract, IncrementContractClient};
use soroban_sdk::{testutils::Events as _, Env};

mod deployed {
   soroban_sdk::contractimport!(file = "contract.wasm");
}

#[test]
fn differential_test() {
   let env = Env::default();
   assert_eq!(
       // Baseline – the deployed contract
       {
           let contract_id = env.register(deployed::WASM, ());
           let client = IncrementContractClient::new(&env, &contract_id);
           (
               // Return Values
               (
                   client.increment(),
                   client.increment(),
                   client.increment(),
               ),
               // Events
               env.events.all(),
           )
       },
       // Local – the changed or refactored contract
       {
           let contract_id = env.register(IncrementContract, ());
           let client = IncrementContractClient::new(&env, &contract_id);
           (
               // Return Values
               (
                   client.increment(),
                   client.increment(),
                   client.increment(),
               ),
               // Events
               env.events.all(),
           )
       },
   );
}

Para saber más sobre cómo escribir pruebas diferenciales, consulta la guía práctica sobre Pruebas Diferenciales.

Medir la cobertura del código utiliza herramientas para identificar líneas de código que son y no son ejecutadas por pruebas. Las estadísticas de cobertura de código pueden darnos una idea de cuánto de un contrato es realmente probado por sus pruebas.

Una forma de identificar código no probado es usar herramientas de cobertura de código para contar e identificar líneas de código que no son ejecutadas por pruebas.

En pruebas unitarias e integración, la herramienta Rust cargo-llvm-cov informará estadísticas de cobertura de código e identificará líneas. Ver Cobertura de Código.

En pruebas de fuzzing, la herramienta Rust cargo-fuzz contiene funcionalidad de cobertura. Ver Fuzzing.

Otra forma de identificar código no probado es con pruebas de mutación. Las pruebas de mutación hacen cambios en un programa para identificar cambios que se pueden hacer que no son detectados por las pruebas.

La herramienta Rust cargo-mutants puede ser usada para pruebas de mutación de contratos. Ver Pruebas de Mutación.