Testing
Con el tiempo, las pruebas se convierten en un componente crucial del proceso de desarrollo de contratos inteligentes. Las pruebas garantizan que las modificaciones puedan integrarse rápidamente en la base de código del contrato sin causar interrupciones en otros elementos.
Por lo general, un conjunto de contratos bien diseñados tendrá un amplio conjunto de pruebas divididas en dos categorías: Pruebas unitarias y Pruebas de integración.
Test unitarios
Para obtener información general sobre las pruebas unitarias, consulte Pruebas.
Pruebas de integración con cw-multi-test
El paquete cw-multi-test ofrecido en el repositorio cw-plus proporciona una forma interesante de probar tus contratos inteligentes sin tener que desplegarlos completamente en una testnet. Antes de la disponibilidad del paquete multi-test, el flujo de trabajo típico implicaba tener una tubería que establecería los contratos en una cadena específica (como una testnet o red local), realizar pruebas y luego, si era posible, destruir o autodestruir esos contratos.
conceptos cw-multiprueba
Hay algunos conceptos clave que debes entender antes de poder simular un entorno blockchain en Rust y ejecutar pruebas que impliquen interacciones contrato-contrato y contrato-banco.
En esta sección, tomaremos un enfoque paso a paso en la escritura de una prueba con cw-multi-test, mientras explicamos algunos conceptos importantes en el camino.
Para empezar, necesitamos un contrato de ejemplo, como el cw-template, que es un contrato boilerplate simple con dos funciones: Incrementar y Reiniciar.
Comenzamos creando un nuevo archivo de prueba con las siguientes importaciones:
Las importaciones anteriores nos proporcionan una amplia gama de herramientas para crear una prueba. La primera importación a tener en cuenta es App, que servirá como el entorno blockchain simulado en el que se ejecutarán nuestras pruebas.
App
El principal punto de entrada al sistema se llama App, que representa una aplicación blockchain. Mantiene un registro de la altura y la hora del bloque, que puedes modificar para simular múltiples bloques. Puedes utilizar app.update_block(next_block) para incrementar la marca de tiempo en 5s y la altura en 1 (simulando un nuevo bloque), o puedes escribir cualquier otro mutador para avanzar más.
La aplicación proporciona el punto de entrada App.execute que permite ejecutar cualquier mensaje CosmosMsg y lo envuelve como una transacción atómica. Si execute tiene éxito, el estado se confirmará. Devuelve los datos y una lista de eventos en caso de ejecución correcta o un Err(String) en caso de error. Existen algunos métodos de ayuda asociados al rasgo Executor que crean el CosmosMsg por ti, ofreciendo una API menos verbosa. Los métodos instantiate_contract, execute_contract y send_tokens se proporcionan para tu comodidad a la hora de escribir pruebas. Cada uno de estos métodos ejecuta un mensaje CosmosMsg de forma atómica como si fuera enviado por un usuario. Si quieres ejecutar varios mensajes a la vez y revertir todo el estado si alguno falla, también puedes utilizar el método execute_multi.
El otro punto de entrada clave a App es la interfaz Querier que implementa. En particular, puedes usar App.wrap() para obtener un QuerierWrapper, que proporciona todo tipo de APIs para consultar la cadena de bloques, como all_balances y query_wasm_smart. Juntando todo esto, tienes un Almacenamiento envuelto en una aplicación, donde puedes ejecutar contratos y bancos, consultarlos fácilmente, y actualizar el BlockInfo actual, en una API que no es muy verbosa o engorrosa. Bajo el capó, procesará todos los mensajes devueltos por los contratos, moverá los tokens del "banco" y llamará a otros contratos.
El otro punto de entrada clave a App es la interfaz Querier que implementa. En particular, puedes usar App.wrap() para obtener un QuerierWrapper, que proporciona todo tipo de APIs para consultar la cadena de bloques, como all_balances y query_wasm_smart. Juntando todo esto, tienes un Almacenamiento envuelto en una aplicación, donde puedes ejecutar contratos y bancos, consultarlos fácilmente, y actualizar el BlockInfo actual, en una API que no es muy verbosa o engorrosa. Bajo el capó, procesará todos los mensajes devueltos por los contratos, moverá los tokens del "banco" y llamará a otros contratos.
El otro aspecto importante de App es la interfaz Querier que implementa. Puedes usar el método App.wrap() para obtener un QuerierWrapper, que proporciona varias APIs convenientes para consultar el blockchain, como all_balances y query_wasm_smart. Esto le permite acceder fácilmente al Almacenamiento y ejecutar contratos, bancos y consultas. También permite actualizar el BlockInfo actual en una API sencilla y fácil de usar. Internamente, gestiona todos los mensajes devueltos por los contratos, transfiere tokens de "banco" e invoca otros contratos.
Puede crear una App para utilizarla en su código de prueba del siguiente modo:
Simulación de contratos
La simulación de contratos es uno de los mantras de las pruebas múltiples, pero también presenta uno de los principales obstáculos para el éxito de las pruebas. Para empezar, cualquier contrato que desee probar debe ser imitado o envuelto. El cw-multi-test ofrece un ContractWrapper que le permite encapsular los componentes lógicos de su contrato, como la instanciación, la ejecución y las consultas, y desplegarlo en una red burlada.
La simulación de todos sus contratos y luego probar cada uno se puede lograr en un estilo de secuencias de comandos, pero en aras de la mantenibilidad, se recomienda definir todos sus contratos envueltos como funciones para que pueda reutilizarlos:
El anterior es un ejemplo más complejo, pero vamos a desglosarlo rápidamente. Importamos las funciones execute, instantiate, Query y Reply, que son utilizadas en tiempo de ejecución por el contrato, y luego creamos nuestro wrapper para utilizarlo en las pruebas.
Informacion
Responder o no responder: Esa es la cuestión.
Dependiendo de la estructura de su contrato, al crear un ContractWrapper, puede que no necesite with_reply si su contrato no tiene implementada una función Reply.
Después de burlarse de un contrato, seguirán dos pasos más: almacenar el código y luego configurar un contrato a partir del objeto de código. Notarás que este es exactamente el mismo proceso para desplegar a una cadena testnet o mainnet. En las pruebas unitarias, se trabaja con un mocked_env, utilizando mock_dependencies y pasando mock_info.
Almacenamiento e instanciación de un contrato:
Antes de poder instanciar un contrato en un entorno cw-multi-test, primero hay que almacenarlo. Una vez almacenado, el contrato puede ser instanciado utilizando su code_id asociado.
Instanciar desde el nuevo objeto de código:
Todo lo anterior le da un contrato simulado. A medida que comience las pruebas, puede encontrar errores como:
No ContractData
Contract <contract> does not exist
Si te encuentras con alguno de ellos, lo más probable es que te falte un mock. En el entorno cw-multi-test, cualquier cosa que pueda ser considerada un contrato, o cualquier cosa con la que su contrato interactúe, debe ser imitado. Esto incluye tu propio contrato de utilidad simple y cualquier servicio con el que interactúe, incluso si no tienes intención de probarlo inmediatamente.
Mira tu contrato y comprueba si estás pasando alguna dirección de contrato ficticia, ya que esta es la causa más probable. Si encuentras alguno, deberías: simularlo usando el método descrito anteriormente, instanciarlo usando el método descrito anteriormente, capturar su dirección, y pasarlo en lugar de un dummy. Ahora, vamos a pasar a la siguiente cuestión importante: mocking otros servicios.
Informacion
Una dirección debe estar en minúsculas alfanuméricas para ser considerada válida. Por ejemplo, "owner" es válido, pero "Owner" no lo es.
Ponerlo todo junto
Simulación de contratos con terceros
Si has leído la sección anterior, deberías tener una comprensión general de la cantidad de trabajo necesario para simular tus contratos. A medida que continúe simulando y probando, es posible que se encuentre con un obstáculo cuando se dé cuenta de que sus contratos interactúan con Terraswap, Anchor, o algún otro servicio en el IBC. Pero no te preocupes, no es un gran problema.
Puede que empieces a intentar imitar uno de estos servicios de la misma manera que se ha descrito anteriormente, sólo para darte cuenta de que necesitas acceder al código. El código del contrato es lo que importas para obtener execute, instantiate y Query. Sin embargo, puedes notar que los protocolos no incluyen su código de contrato en sus paquetes Rust; sólo incluyen lo que necesitas para interactuar con ellos, como mensajes y algunos ayudantes.
Sin embargo, no toda la esperanza está perdida. Todavía puedes progresar intentando crear una imitación del servicio con el que interactúas. El proceso es similar al de imitar tus contratos (como se describió anteriormente), excepto que necesitarás implementar toda la funcionalidad. Esta tarea es más fácil porque puedes crear un ExecuteMsg más pequeño con sólo la función que usas, o un manejador Query mock con sólo las consultas que necesitas. Aquí hay un ejemplo de nuestro mock para un contrato de terceros:
Cuando defines tu propio mocked contract, tienes mucha flexibilidad. Puedes omitir dependencias, entorno y variables de información usando _ si no se usan, y puedes devolver cualquier respuesta deseada para un ExecuteMsg o Query dado. El reto se convierte entonces en cómo simular todos estos servicios.
Last updated