Docs
⌘ K

28 minutes

Cadre pour les tests unitaires

Apprenez à utiliser Matchstick, un cadre de test unitaire développé par LimeChain⁠. Matchstick permet aux développeurs de subgraphs de tester leur logique de mappages dans un environnement sandbox et de déployer avec succès leurs subgraphs.

Avantages de l’utilisation de Matchstick

  • Il est écrit en Rust et optimisé pour des hautes performances.
  • Il vous donne accès à des fonctions de développement, notamment la possibilité de simuler des appels de contrat, de faire des assertions sur l’état du store, de surveiller les échecs du subgraph, de vérifier les performances des tests, et bien d’autres choses encore.

Introduction

Installation des dépendances

Pour utiliser les méthodes d’aide aux tests et exécuter les tests, vous devez installer les dépendances suivantes :

yarn add --dev matchstick-as

Installer PostgreSQL

graph-node dépend de PostgreSQL, donc si vous ne l’avez pas déjà, vous devrez l’installer.

Remarque : Il est fortement recommandé d’utiliser les commandes ci-dessous pour éviter les erreurs inattendues.

En utilisant MacOS

Commande d’installation :

brew install postgresql

Créez un lien symbolique vers la dernière version de libpq.5.lib Vous devrez peut-être créer ce répertoire d’abord /usr/local/opt/postgresql/lib/

ln -sf /usr/local/opt/postgresql@14/lib/postgresql@14/libpq.5.dylib /usr/local/opt/postgresql/lib/libpq.5.dylib

En utilisant Linux

Commande d’installation (dépend de votre distribution) :

sudo apt installer postgresql

En utilisant WSL (Windows Subsystem for Linux)

Vous pouvez utiliser Matchstick sur WSL en utilisant à la fois l’approche Docker et l’approche binaire. Comme WSL peut être un peu délicat, voici quelques conseils au cas où vous rencontreriez des problèmes tels que

static BYTES = Symbol("Bytes") SyntaxError: Unexpected token =

ou bien

<PROJECT_PATH>/node_modules/gluegun/build/index.js:13 throw up;

Veuillez vous assurer que vous êtes sur une version plus récente de Node.js graph-cli ne prend plus en charge v10.19.0, et c’est toujours la version par défaut pour les nouvelles images Ubuntu sur le WSL. Par exemple, il est confirmé que Matchstick fonctionne sur WSL avec v18.1.0, vous pouvez passer à cette version via nvm ou si vous mettez à jour votre Node.js global. N’oubliez pas de supprimer node_modules et de relancer npm install après avoir mis à jour votre nodejs ! Ensuite, assurez-vous que libpq est installé, vous pouvez le faire en exécutant

sudo apt-get install libpq-dev

Et enfin, n’utilisez pas graph test (qui utilise votre installation globale de graph-cli et pour une raison quelconque, il semble qu’il soit cassé sur WSL actuellement), utilisez plutôt yarn test ou npm run test (qui utilisera l’instance locale, au niveau du projet, de graph-cli, ce qui fonctionne comme un charme). Pour cela, vous devez bien sûr avoir un script " test " dans votre fichier package.json qui peut être quelque chose d’aussi simple que

{  "name": "demo-subgraph",  "version": "0.1.0",  "scripts": {    "test": "graph test",    ...  },  "dependencies": {    "@graphprotocol/graph-cli": "^0.56.0",    "@graphprotocol/graph-ts": "^0.31.0",    "matchstick-as": "^0.6.0"  }}

En utilisant Matchstick

Pour utiliser Matchstick dans votre projet Subgraph, ouvrez simplement un terminal, naviguez jusqu’au dossier racine de votre projet et lancez simplement graph test [options] <datasource> - il télécharge le dernier binaire Matchstick et exécute le test spécifié ou tous les tests dans un dossier de test (ou tous les tests existants si aucun flag de source de données n’est spécifié).

CLI options

Cette opération permet d’exécuter tous les tests contenus dans le dossier test :

graph test

Ceci lancera un test nommé gravity.test.ts et/ou tous les tests à l’intérieur d’un dossier nommé gravity :

gravity graph test

Ce fichier de test sera le seul à être exécuté :

graph test path/to/file.test.ts

Options:

-c, --coverage                Exécute les tests en mode couverture-d, --docker                  Exécute les tests dans un conteneur Docker (Note : Exécute à partir du dossier racine du subgraph).-f, --force                   Binaire : Redécharge le binaire. Docker : Redécharge le fichier Docker et reconstruit l'image Docker.-h, --help                    Affiche les informations sur l'utilisation-l, --logs                    Enregistre dans la console des informations sur le système d'exploitation, le modèle de processeur et l'adresse de téléchargement (à des fins de débogage).-r, --recompile               Oblige à recompiler les tests-v, --version <tag>           Choisi la version du binaire rust que vous souhaitez télécharger/utiliser

Docker

Depuis graph-cli 0.25.2, la commande graph test supporte l’exécution de matchstick dans un conteneur docker avec l’option -d. L’implémentation de docker utilise bind mount⁠ pour ne pas avoir à reconstruire l’image de docker à chaque fois que la commande graph test -d est exécutée. Vous pouvez également suivre les instructions du dépôt matchstick⁠ pour exécuter docker manuellement.

❗ graph test -d force docker run à s’exécuter avec le flag -t. Ceci doit être supprimé pour fonctionner dans des environnements non-interactifs (comme GitHub CI).

❗ Si vous avez précédemment exécuté graph test, vous pouvez rencontrer l’erreur suivante lors du build de docker :

error from sender: failed to xattr node_modules/binary-install-raw/bin/binary-<platform>: permission denied

Dans ce cas, créez un .dockerignore dans le dossier racine et ajoutez node_modules/binary-install-raw/bin

La Configuration

Matchstick peut être configuré pour utiliser un chemin personnalisé pour les tests, les librairies et les manifestes via le fichier de configuration matchstick.yaml :

testsFolder: path/to/testslibsFolder: path/to/libsmanifestPath: path/to/subgraph.yaml

Subgraph Demo

Vous pouvez essayer et jouer avec les exemples de ce guide en clonant le dépôt du Demo Subgraph.⁠

Tutoriels vidéos

Vous pouvez également consulter la série de vidéos sur “Comment utiliser Matchstick pour écrire des tests unitaires pour vos subgraphs” ⁠

Structure des tests

IMPORTANT : La structure de test décrite ci-dessous dépend de la version de matchstick-as >=0.5.0

décrivez()

describe(name : String , () => {}) - Définit un groupe de test.

Notes:

  • Les descriptions ne sont pas obligatoires. Vous pouvez toujours utiliser test() à l’ancienne, en dehors des blocs describe()

L’exemple:

import { describe, test } from "matchstick-as/assembly/index"import { handleNewGravatar } from "../../src/gravity"describe("handleNewGravatar()", () => {  test("Il faut créer une nouvelle entité Gravatar", () => {    ...  })})

Exemple imbriqué de describe() :

import { describe, test } from "matchstick-as/assembly/index"import { handleUpdatedGravatar } from "../../src/gravity"describe("handleUpdatedGravatar()", () => {  describe("Lorsque l'entité existe", () => {    test("met à jour l'entité", () => {      ...    })  })  describe("Lorsque l'entité n'existe pas", () => {    test("il crée une nouvelle entité", () => {      ...    })  })})

tester ()

test(name : String, () =>, should_fail : bool) - Définit un cas de test. Vous pouvez utiliser test() à l’intérieur des blocs describe() ou indépendamment.

L’exemple:

import { describe, test } from "matchstick-as/assembly/index"import { handleNewGravatar } from "../../src/gravity"describe("handleNewGravatar()", () => {  test("Doit créer une nouvelle entité", () => {    ...  })})

ou bien

test("handleNewGravatar() devrait créer une nouvelle entité", () => {  ...})

avantTout()

Exécute un bloc de code avant tous les tests du fichier. Si beforeAll est déclaré à l’intérieur d’un bloc describe, il s’exécute au début de ce bloc describe.

Les Exemples:

Le code contenu dans beforeAll s’exécutera une fois avant tous les tests du fichier.

import { describe, test, beforeAll } from "matchstick-as/assembly/index"import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"import { Gravatar } from "../../generated/schema"beforeAll(() => {  let gravatar = new Gravatar("0x0")  gravatar.displayName = “First Gravatar”  gravatar.save()  ...})describe("Lorsque l'entité n'existe pas", () => {  test("il devrait créer un nouveau Gravatar avec l'identifiant 0x1", () => {    ...  })})describe("Lorsque l'entité existe déjà", () => {  test("il devrait mettre à jour le Gravatar avec l'identifiant 0x0", () => {    ...  })})

Le code contenu dans beforeAll sera exécuté une fois avant tous les tests du premier bloc de description

import { describe, test, beforeAll } from "matchstick-as/assembly/index"import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"import { Gravatar } from "../../generated/schema"describe("handleUpdatedGravatar()", () => {  beforeAll(() => {    let gravatar = new Gravatar("0x0")    gravatar.displayName = “First Gravatar”    gravatar.save()    ...  })  test("met à jour le Gravatar avec l'identifiant 0x0", () => {    ...  })  test("crée un nouveau Gravatar avec l'identifiant 0x1", () => {    ...  })})

afterAll()

Exécute un bloc de code après tous les tests du fichier. Si afterAll est déclaré à l’intérieur d’un bloc describe, il s’exécute à la fin de ce bloc describe.

L’exemple:

Le code contenu dans afterAll sera exécuté une fois après tous les tests du fichier.

import { describe, test, afterAll } from "matchstick-as/assembly/index"import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"import { store } from "@graphprotocol/graph-ts"afterAll(() => {  store.remove("Gravatar", "0x0")  ...})describe("handleNewGravatar, () => {  test("creates Gravatar with id 0x0", () => {    ...  })})describe("handleUpdatedGravatar", () => {  test("updates Gravatar with id 0x0", () => {    ...  })})

Le code contenu dans afterAll sera exécuté une fois après tous les tests du premier bloc de description

import { describe, test, afterAll, clearStore } from "matchstick-as/assembly/index"import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"describe("handleNewGravatar", () => {	afterAll(() => {    store.remove("Gravatar", "0x1")    ...	})  test("Il crée une nouvelle entité avec l'identifiant 0x0.", () => {    ...  })  test("Il crée une nouvelle entité avec l'identifiant 0x1", () => {    ...  })})describe("handleUpdatedGravatar", () => {  test("updates Gravatar with id 0x0", () => {    ...  })})

beforeEach()

Exécute un bloc de code avant chaque test. Si beforeEach est déclaré à l’intérieur d’un bloc describe, il s’exécute avant chaque test dans ce bloc describe.

Exemples : Le code contenu dans beforeEach sera exécuté avant chaque test.

import { describe, test, beforeEach, clearStore } from "matchstick-as/assembly/index"import { handleNewGravatars } from "./utils"beforeEach(() => {  clearStore() // <-- nettoye le store avant chaque test dans le fichier})describe("handleNewGravatars, () => {  test("Un test qui nécessite un store propre", () => {    ...  })  test("Second, qui nécessite un store propre", () => {    ...  })}) ...

Le code contenu dans beforeEach ne s’exécutera qu’avant chaque test de la description

import { describe, test, beforeEach } from 'matchstick-as/assembly/index'import { handleUpdatedGravatar, handleNewGravatar } from '../../src/gravity'describe('handleUpdatedGravatars', () => {  beforeEach(() => {    let gravatar = new Gravatar('0x0')    gravatar.displayName = 'First Gravatar'    gravatar.imageUrl = ''    gravatar.save()  })  test('Met à jour le nom d'affichage (displayName)', () => {    assert.fieldEquals('Gravatar', '0x0', 'displayName', 'First Gravatar')    // code qui devrait mettre à jour le nom d'affichage (displayName) pour le 1er Gravatar    assert.fieldEquals('Gravatar', '0x0', 'displayName', '1st Gravatar')    store.remove('Gravatar', '0x0')  })  test('Met à jour l'imageUrl', () => {    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', '')    // code qui devrait changer l'imageUrl en https://www.gravatar.com/avatar/0x0    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', 'https://www.gravatar.com/avatar/0x0')    store.remove('Gravatar', '0x0')  })})

afterEach()

Exécute un bloc de code après chaque test. Si afterEach est déclaré à l’intérieur d’un bloc describe, il s’exécute après chaque test dans ce bloc describe.

Les Exemples:

Le code contenu dans afterEach sera exécuté après chaque test.

import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"beforeEach(() => {  let gravatar = new Gravatar("0x0")  gravatar.displayName = “First Gravatar”  gravatar.save()})afterEach(() => {  store.remove("Gravatar", "0x0")})describe("handleNewGravatar", () => {  ...})describe("handleUpdatedGravatar", () => {  test("Met à jour le nom d'affichage (displayName)", () => {     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")    // code qui devrait mettre à jour le nom d'affichage (displayName) pour le 1er Gravatar    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")  })  test("Met à jour l'imageUrl", () => {    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")    // code qui devrait changer l'imageUrl en https://www.gravatar.com/avatar/0x0    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")  })})

Le code contenu dans afterEach sera exécuté après chaque test de cette description

import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"describe("handleNewGravatar", () => {  ...})describe("handleUpdatedGravatar", () => {  beforeEach(() => {    let gravatar = new Gravatar("0x0")    gravatar.displayName = "First Gravatar"    gravatar.imageUrl = ""    gravatar.save()  })  afterEach(() => {    store.remove("Gravatar", "0x0")  })  test("Met à jour le nom d'affichage (displayName)", () => {     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")    // code qui devrait mettre à jour le nom d'affichage (displayName) pour le 1er Gravatar    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")  })  test("Met à jour l'imageUrl", () => {    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")    // code qui devrait changer l'imageUrl en https://www.gravatar.com/avatar/0x0    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")  })})

Assertions

fieldEquals(entityType: string, id: string, fieldName: string, expectedVal: string)equals(expected: ethereum.Value, actual: ethereum.Value)notInStore(entityType: string, id: string)addressEquals(address1: Address, address2: Address)bytesEquals(bytes1: Bytes, bytes2: Bytes)i32Equals(number1: i32, number2: i32)bigIntEquals(bigInt1: BigInt, bigInt2: BigInt)booleanEquals(bool1: boolean, bool2: boolean)stringEquals(string1: string, string2: string)arrayEquals(array1: Array<ethereum.Value>, array2: Array<ethereum.Value>)tupleEquals(tuple1: ethereum.Tuple, tuple2: ethereum.Tuple)assertTrue(value: boolean)assertNull<T>(value: T)assertNotNull<T>(value: T)entityCount(entityType: string, expectedCount: i32)

À partir de la version 0.6.0, les assertions supportent également les messages d’erreur personnalisés

assert.fieldEquals('Gravatar', '0x123', 'id', '0x123', 'Id doit être 0x123')assert.equals(ethereum.Value.fromI32(1), ethereum.Value.fromI32(1), 'La valeur doit être égale à 1')assert.notInStore('Gravatar', '0x124', 'Gravatar ne devrait pas être dans le store')assert.addressEquals(Address.zero(), Address.zero(), 'L'adresse doit être zéro')assert.bytesEquals(Bytes.fromUTF8('0x123'), Bytes.fromUTF8('0x123'), 'Les Bytes doivent être égaux')assert.i32Equals(2, 2, 'I32 doit être égal à 2')assert.bigIntEquals(BigInt.fromI32(1), BigInt.fromI32(1), 'BigInt doit être égal à 1')assert.booleanEquals(true, true, 'Le booléen doit être vrai')assert.stringEquals('1', '1', 'La Chaîne de caractère doit être égale à 1')assert.arrayEquals([ethereum.Value.fromI32(1)], [ethereum.Value.fromI32(1)], 'Les tableaux doivent être égaux')assert.tupleEquals(  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),  'Les tuples doivent être égaux',)assert.assertTrue(true, 'Devrait être vrai')assert.assertNull(null, 'Devrait être null')assert.assertNotNull('not null', 'Doit être non null')assert.entityCount('Gravatar', 1, 'Il devrait y avoir 2 gravatars')assert.dataSourceCount('GraphTokenLockWallet', 1, 'Le modèle GraphTokenLockWallet doit avoir une source de données')assert.dataSourceExists(  'GraphTokenLockWallet',  Adresse.zero().toHexString(),  'GraphTokenLockWallet doit avoir une source de données pour zéro adresse',)

Écrire un test unitaire

Voyons à quoi ressemblerait un test unitaire simple en utilisant les exemples de Gravatar dans le Subgraph de Démo⁠.

En supposant que nous disposions de la fonction de traitement suivante (ainsi que de deux fonctions d’aide pour nous faciliter la vie) :

export function handleNewGravatar(event: NewGravatar): void {  let gravatar = new Gravatar(event.params.id.toHex())  gravatar.owner = event.params.owner  gravatar.displayName = event.params.displayName  gravatar.imageUrl = event.params.imageUrl  gravatar.save()}export function handleNewGravatars(events: NewGravatar[]): void {  events.forEach((event) => {    handleNewGravatar(event)  })}export function createNewGravatarEvent(  id: i32,  ownerAddress: string,  displayName: string,  imageUrl: string,): NewGravatar {  let mockEvent = newMockEvent()  let newGravatarEvent = new NewGravatar(    mockEvent.address,    mockEvent.logIndex,    mockEvent.transactionLogIndex,    mockEvent.logType,    mockEvent.block,    mockEvent.transaction,    mockEvent.parameters,  )  newGravatarEvent.parameters = new Array()  let idParam = new ethereum.EventParam('id', ethereum.Value.fromI32(id))  let addressParam = new ethereum.EventParam(    'ownerAddress',    ethereum.Value.fromAddress(Address.fromString(ownerAddress)),  )  let displayNameParam = new ethereum.EventParam('displayName', ethereum.Value.fromString(displayName))  let imageUrlParam = new ethereum.EventParam('imageUrl', ethereum.Value.fromString(imageUrl))  newGravatarEvent.parameters.push(idParam)  newGravatarEvent.parameters.push(addressParam)  newGravatarEvent.parameters.push(displayNameParam)  newGravatarEvent.parameters.push(imageUrlParam)  return newGravatarEvent}

Nous devons tout d’abord créer un fichier de test dans notre projet. Voici un exemple de ce à quoi cela pourrait ressembler :

import { clearStore, test, assert } from 'matchstick-as/assembly/index'import { Gravatar } from '../../generated/schema'import { NewGravatar } from '../../generated/Gravity/Gravity'import { createNewGravatarEvent, handleNewGravatars } from '../mappings/gravity'test('Possibilité d'appeler des mappages avec des événements personnalisés', () => {  // Créer une entité de test et la sauvegarder dans le store en tant qu'état initial (optionnel)  let gravatar = new Gravatar('gravatarId0')  gravatar.save()  // Créer des événements fictifs  let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')  let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')  // Appeler les fonctions de mappage en passant par les événements que nous venons de créer  handleNewGravatars([newGravatarEvent, anotherGravatarEvent])  // Affirmer l'état du store  assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')  assert.fieldEquals('Gravatar', '12345', 'owner', '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')  assert.fieldEquals('Gravatar', '3546', 'displayName', 'cap')  // Effacer le store afin de commencer le prochain test sur une ardoise propre  clearStore()})test('Next test', () => {  //...})

Cela fait beaucoup à décortiquer ! Tout d’abord, une chose importante à noter est que nous importons des choses à partir de matchstick-as, notre bibliothèque d’aide AssemblyScript (distribuée comme un module npm). Vous pouvez trouver le dépôt ici⁠. matchstick-as nous fournit des méthodes de test utiles et définit également la fonction test() que nous utiliserons pour construire nos blocs de test. Le reste est assez simple - voici ce qui se passe :

  • Mettons en place notre état initial et ajoutons une entité Gravatar personnalisée ;
  • Nous définissons deux objets d’événement NewGravatar avec leurs données, en utilisant la fonction createNewGravatarEvent() ;
  • Nous appelons les méthodes de gestion de ces événements - handleNewGravatars() et nous passons la liste de nos événements personnalisés ;
  • Affirmons l’état du magasin. Comment cela fonctionne-t-il ? - Nous passons une combinaison unique de type d’entité et d’identifiant. Ensuite, nous vérifions un champ spécifique de cette entité et affirmons qu’il a la valeur que nous attendons. Nous faisons cela à la fois pour l’entité Gravatar initiale que nous avons ajoutée au magasin, ainsi que pour les deux entités Gravatar qui sont ajoutées lorsque la fonction de gestion est appelée ;
  • Enfin, nous nettoyons le store en utilisant clearStore() afin que notre prochain test puisse commencer avec un objet de store frais et vide. Nous pouvons définir autant de blocs de test que nous le souhaitons.

Et voilà, nous avons formulé notre premier test ! 👏

Maintenant, pour exécuter nos tests, il vous suffit d’exécuter ce qui suit dans le dossier racine de Subgraph :

graph test Gravity

Et si tout se passe bien, vous devriez être accueilli par ce qui suit :

Matchstick avec le message “Tous les tests sont réussis!”

Scénarios de tests actuels

L’Hydratation du magasin avec un certain état

Les utilisateurs peuvent hydrater le magasin avec un ensemble connu d’entités. Voici un exemple pour initialiser la boutique avec une entité Gravatar :

laissez gravatar = new Gravatar('entryId')gravatar.save()

Appel d’une fonction de cartographie avec un événement

Un utilisateur peut créer un événement personnalisé et le transmettre à une fonction de cartographie liée au magasin :

import { store } from 'matchstick-as/assembly/store'import { NewGravatar } from '../../generated/Gravity/Gravity'import { handleNewGravatars, createNewGravatarEvent } from './mapping'let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')handleNewGravatar(newGravatarEvent)

Appel de tous les mappages avec des projecteurs d’événements

Les utilisateurs peuvent appeler les mappages avec des dispositifs de test.

import { NewGravatar } from '../../generated/Gravity/Gravity'import { store } from 'matchstick-as/assembly/store'import { handleNewGravatars, createNewGravatarEvent } from './mapping'let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
export function handleNewGravatars(events: NewGravatar[]): void {    events.forEach(event => {        handleNewGravatar(event);    });}

Appels de contrat moqueurs

Les utilisateurs peuvent simuler des appels de contrat :

import { addMetadata, assert, createMockedFunction, clearStore, test } from 'matchstick-as/assembly/index'import { Gravity } from '../../generated/Gravity/Gravity'import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')let expectedResult = Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947')let bigIntParam = BigInt.fromString('1234')createMockedFunction(contractAddress, 'gravatarToOwner', 'gravatarToOwner(uint256):(address)')  .withArgs([ethereum.Value.fromSignedBigInt(bigIntParam)])  .returns([ethereum.Value.fromAddress(Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947'))])let gravity = Gravity.bind(contractAddress)let result = gravity.gravatarToOwner(bigIntParam)assert.equals(ethereum.Value.fromAddress(expectedResult), ethereum.Value.fromAddress(result))

Comme démontré, afin de se moquer d’un appel de contrat et d’obtenir une valeur de retour, l’utilisateur doit fournir une adresse de contrat, un nom de fonction, une signature de fonction, un tableau d’arguments et bien sûr – la valeur de retour.

Utilisateurs peuvent également simuler des annulations de fonctions :

laissez contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')createMockedFunction(contractAddress, 'getGravatar', 'getGravatar(address):(string,string)')   .withArgs([ethereum.Value.fromAddress(contractAddress)])   .reverts()

Se moquer des fichiers IPFS (à partir de Matchstick 0.4.1)

Les utilisateurs peuvent simuler des fichiers IPFS en utilisant la fonction mockIpfsFile(hash, filePath). La fonction accepte deux arguments, le premier étant le hash/chemin du fichier IPFS et le second le chemin d’un fichier local.

NOTE : Lorsque l’on teste ipfs.map/ipfs.mapJSON, la fonction callback doit être exportée depuis le fichier de test afin que matchtick la détecte, comme la fonction processGravatar() dans l’exemple de test ci-dessous :

Ficher .test.ts :

import { assert, test, mockIpfsFile } from 'matchstick-as/assembly/index'import { ipfs } from '@graphprotocol/graph-ts'import { gravatarFromIpfs } from './utils'// Exporter le callback ipfs.map() pour qu'il soit détecté par matchstickexport { processGravatar } from './utils'test('ipfs.cat', () => {  mockIpfsFile('ipfsCatfileHash', 'tests/ipfs/cat.json')  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)  gravatarFromIpfs()  assert.entityCount(GRAVATAR_ENTITY_TYPE, 1)  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'imageUrl', 'https://i.ytimg.com/vi/MELP46s8Cic/maxresdefault.jpg')  clearStore()})test('ipfs.map', () => {  mockIpfsFile('ipfsMapfileHash', 'tests/ipfs/map.json')  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)  ipfs.map('ipfsMapfileHash', 'processGravatar', Value.fromString('Gravatar'), ['json'])  assert.entityCount(GRAVATAR_ENTITY_TYPE, 3)  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'displayName', 'Gravatar1')  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '2', 'displayName', 'Gravatar2')  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '3', 'displayName', 'Gravatar3')})

Fichier utils.ts :

import { Address, ethereum, JSONValue, Value, ipfs, json, Bytes } from "@graphprotocol/graph-ts"import { Gravatar } from "../../generated/schema"...// rappel ipfs.mapexport function processGravatar(value: JSONValue, userData: Value): void {  // Consultez la documentation de JSONValue pour plus de détails sur la façon de traiter les données.  // avec JSON values  let obj = value.toObject()  let id = obj.get('id')  if (!id) {    return  }  // Des entités de rappel peuvent également être créées  let gravatar = new Gravatar(id.toString())  gravatar.displayName = userData.toString() + id.toString()  gravatar.save()}// fonction qui appelle ipfs.catexport function gravatarFromIpfs(): void {  let rawData = ipfs.cat("ipfsCatfileHash")  if (!rawData) {    return  }  let jsonData = json.fromBytes(rawData as Bytes).toObject()  let id = jsonData.get('id')  let url = jsonData.get("imageUrl")  if (!id || !url) {    return  }  let gravatar = new Gravatar(id.toString())  gravatar.imageUrl = url.toString()  gravatar.save()}

Affirmation de l’état du magasin

Les utilisateurs sont en mesure d’affirmer l’état final (ou intermédiaire) du magasin via des entités d’affirmation. Pour ce faire, l’utilisateur doit fournir un type d’entité, l’ID spécifique d’une entité, le nom d’un champ sur cette entité et la valeur attendue du champ. Voici un exemple rapide:

import { assert } from 'matchstick-as/assembly/index'import { Gravatar } from '../generated/schema'let gravatar = new Gravatar('gravatarId0')gravatar.save()assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')

L’exécution de la fonction assert.fieldEquals() permet de vérifier l’égalité du champ donné par rapport à la valeur attendue donnée. Le test échouera et un message d’erreur sera affiché si les valeurs NE SONT PAS égales. Dans le cas contraire, le test passera avec succès.

Interagir avec les métadonnées d’événement

Les utilisateurs peuvent utiliser les métadonnées de transaction par défaut, qui peuvent être reenvoyées comme un ethereum.Event en utilisant la fonction newMockEvent(). L’exemple suivant montre comment vous pouvez lire/écrire dans ces champs de l’objet Event :

// Lisezlet logType = newGravatarEvent.logType// Écrivezlet UPDATED_ADDRESS = '0xB16081F360e3847006dB660bae1c6d1b2e17eC2A'newGravatarEvent.address = Address.fromString(UPDATED_ADDRESS)

Affirmation de l’égalité des variables

assert.equals(ethereum.Value.fromString("bonjour"); ethereum.Value.fromString("bonjour"));

Affirmer qu’une entité n’est PAS dans le store

Les utilisateurs peuvent affirmer qu’une entité n’existe pas dans le magasin. La fonction prend un type d’entité et un identifiant. Si l’entité se trouve effectivement dans le magasin, le test échouera avec un message d’erreur pertinent. Voici un exemple rapide de la façon d’utiliser cette fonctionnalité :

assert.notInStore('Gravatar', '23')

Affichage de tout le magasin ou d’entités individuelles (à des fins de débogage)

Vous pouvez imprimer l’intégralité du magasin sur la console à l’aide de cette fonction d’assistance:

import { logStore } from 'matchstick-as/assembly/store'logStore()

Depuis la version 0.6.0, logStore n’affiche plus les champs dérivés, au lieu de celà les utilisateurs peuvent utiliser la nouvelle fonction logEntity. Bien sûr, logEntity peut être utilisée pour afficher n’importe quelle entité, pas seulement celles qui ont des champs dérivés. logEntity prend le type d’entité, l’identifiant de l’entité et un flag showRelated pour indiquer si les utilisateurs veulent afficher les entités dérivées associées.

import { logEntity } from 'matchstick-as/assembly/store'logEntity("Gravatar", 23, true)

Échec prévu

Les utilisateurs peuvent s’attendre à des échecs de test, en utilisant l’indicateur ShouldFail sur les fonctions test() :

test(  'Devrait générer une erreur',  () => {    throw new Error()  },  true,)

Si le test est marqué avec ShouldFail = true mais n’échoue PAS, cela apparaîtra comme une erreur dans les journaux et le bloc de test échouera. De plus, s’il est marqué avec ShouldFail = false (l’état par défaut), l’exécuteur de test plantera.

Journal de bord

Avoir des journaux personnalisés dans les tests unitaires équivaut exactement à la journalisation des mappages. La différence est que l’objet journal doit être importé depuis matchstick-as plutôt que graph-ts. Voici un exemple simple avec tous les types de journaux non critiques :

import { test } from "matchstick-as/assembly/index";import { log } from "matchstick-as/assembly/log";test("Success", () => {    log.success("Succès!". []);});test("Error", () => {    log.error("Erreur :( ", []);});test("Debug", () => {    log.debug("Deboggage...", []);});test("Info", () => {    log.info("Info!", []);});test("Warning", () => {    log.warning("Avertissement!", []);});

Les utilisateurs peuvent également simuler une panne critique, comme ceci :

test('Tout faire exploser', () => {  log.critical('Boom!')})

La journalisation des erreurs critiques arrêtera l’exécution des tests et fera tout exploser. Après tout, nous voulons nous assurer que votre code ne contient pas de journaux critiques lors du déploiement, et vous devriez le remarquer immédiatement si cela devait se produire.

Tests dérivés

Tester les champs dérivés est une fonctionnalité qui permet aux utilisateurs de définir un champ sur une certaine entité et de faire en sorte qu’une autre entité soit automatiquement mise à jour si elle dérive l’un de ses champs de la première entité.

Avant la version 0.6.0, il était possible d’obtenir les entités dérivées en y accédant en tant que champs/propriétés d’entité, comme suit :

let entity = ExampleEntity.load('id')let derivedEntity = entity.derived_entity

A partir de la version 0.6.0, ceci est fait en utilisant la fonction loadRelated de graph-node, les entités dérivées peuvent être accédées de la même manière que dans les gestionnaires.

test('Derived fields example test', () => {  let mainAccount = GraphAccount.load('12')!  assert.assertNull(mainAccount.get('nameSignalTransactions'))  assert.assertNull(mainAccount.get('operatorOf'))  let operatedAccount = GraphAccount.load('1')!  operatedAccount.operators = [mainAccount.id]  operatedAccount.save()  mockNameSignalTransaction('1234', mainAccount.id)  mockNameSignalTransaction('2', mainAccount.id)  mainAccount = GraphAccount.load('12')!  assert.assertNull(mainAccount.get('nameSignalTransactions'))  assert.assertNull(mainAccount.get('operatorOf'))  const nameSignalTransactions = mainAccount.nameSignalTransactions.load()  const operatorsOfMainAccount = mainAccount.operatorOf.load()  assert.i32Equals(2, nameSignalTransactions.length)  assert.i32Equals(1, operatorsOfMainAccount.length)  assert.stringEquals('1', operatorsOfMainAccount[0].id)  mockNameSignalTransaction('2345', mainAccount.id)  let nst = NameSignalTransaction.load('1234')!  nst.signer = '11'  nst.save()  store.remove('NameSignalTransaction', '2')  mainAccount = GraphAccount.load('12')!  assert.i32Equals(1, mainAccount.nameSignalTransactions.load().length)})

Test de loadInBlock

Depuis la version 0.6.0, les utilisateurs peuvent tester loadInBlock en utilisant le mockInBlockStore, qui permet de simuler des entités dans le cache du bloc.

import { afterAll, beforeAll, describe, mockInBlockStore, test } from 'matchstick-as'import { Gravatar } from '../../generated/schema'describe('loadInBlock', () => {  beforeAll(() => {    mockInBlockStore('Gravatar', 'gravatarId0', gravatar)  })  afterAll(() => {    clearInBlockStore()  })  test('Peut utiliser entity.loadInBlock() pour récupérer l'entité dans le sore du cache du bloc actuel', () => {    let retrievedGravatar = Gravatar.loadInBlock('gravatarId0')    assert.stringEquals('gravatarId0', retrievedGravatar!.get('id')!.toString())  })  test("Renvoit null lors de l'appel à entity.loadInBlock() si une entité n'existe pas dans le bloc actuel", () => {    let retrievedGravatar = Gravatar.loadInBlock('IDoNotExist')    assert.assertNull(retrievedGravatar)  })})

Tester les sources de données dynamiques

Le test des sources de données dynamiques peut être effectué en simulant la valeur de retour des fonctions context(), address() et network() du namespace dataSource. Ces fonctions renvoient actuellement les valeurs suivantes context() - renvoit une entité vide (DataSourceContext), address() - renvoit 0x00000000000000000000000000000000, network() - renvoit mainnet. Les fonctions create(...) et createWithContext(...) sont simulées pour ne rien faire, donc elles n’ont pas besoin d’être appelées dans les tests. Les modifications des valeurs de retour peuvent être faites à travers les fonctions du namespacedataSourceMock dans matchstick-as (version 0.3.0+).

L’exemple ci-dessous :

Nous avons d’abord le gestionnaire d’événements suivant (qui a été intentionnellement réutilisé pour présenter la moquerie de la source de données) :

export function handleApproveTokenDestinations(event: ApproveTokenDestinations): void {  let tokenLockWallet = TokenLockWallet.load(dataSource.address().toHexString())!  if (dataSource.network() == 'rinkeby') {    tokenLockWallet.tokenDestinationsApproved = true  }  let context = dataSource.context()  if (context.get('contextVal')!.toI32() > 0) {    tokenLockWallet.setBigInt('tokensReleased', BigInt.fromI32(context.get('contextVal')!.toI32()))  }  tokenLockWallet.save()}

Et puis nous avons le test utilisant l’une des méthodes de l’espace de noms dataSourceMock pour définir une nouvelle valeur de retour pour toutes les fonctions dataSource :

import { assert, test, newMockEvent, dataSourceMock } from 'matchstick-as/assembly/index'import { BigInt, DataSourceContext, Value } from '@graphprotocol/graph-ts'import { handleApproveTokenDestinations } from '../../src/token-lock-wallet'import { ApproveTokenDestinations } from '../../generated/templates/GraphTokenLockWallet/GraphTokenLockWallet'import { TokenLockWallet } from '../../generated/schema'test('Source de données : simple exemple de simulation ', () => {  let addressString = '0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'  let address = Address.fromString(addressString)  let wallet = new TokenLockWallet(address.toHexString())  wallet.save()  let context = new DataSourceContext()  context.set('contextVal', Value.fromI32(325))  dataSourceMock.setReturnValues(addressString, 'rinkeby', context)  let event = changetype<ApproveTokenDestinations>(newMockEvent())  assert.assertTrue(!wallet.tokenDestinationsApproved)  handleApproveTokenDestinations(event)  wallet = TokenLockWallet.load(address.toHexString())!  assert.assertTrue(wallet.tokenDestinationsApproved)  assert.bigIntEquals(wallet.tokensReleased, BigInt.fromI32(325))  dataSourceMock.resetValues()})

Notez que dataSourceMock.resetValues() est appelé à la fin. C’est parce que les valeurs sont mémorisées lorsqu’elles sont modifiées et doivent être réinitialisées si vous voulez revenir aux valeurs par défaut.

Test de la création dynamique de sources de données

Depuis la version 0.6.0, il est possible de tester si une nouvelle source de données a été créée à partir d’un modèle. Cette fonctionnalité prend en charge à la fois les modèles ethereum/contract et file/ipfs. Il y a quatre fonctions pour cela :

  • assert.dataSourceCount(templateName, expectedCount) peut être utilisé pour affirmer le nombre attendu de sources de données à partir du modèle spécifié
  • assert.dataSourceExists(templateName, address/ipfsHash) affirme qu’une source de données avec l’identifiant spécifié (qui peut être une adresse de contrat ou un hash de fichier IPFS) a été créée à partir d’un modèle spécifié
  • logDataSources(templateName) affiche toutes les sources de données du modèle spécifié sur la console à des fins de débogage
  • readFile(path) lit un fichier JSON qui représente un fichier IPFS et renvoie le contenu sous forme d’octets

Test des modèles ethereum/contrat

test('ethereum/contract dataSource creation example', () => {  // Affirmer qu'il n'y a pas de dataSources créées à partir du modèle GraphTokenLockWallet  assert.dataSourceCount('GraphTokenLockWallet', 0)  // Créer une nouvelle source de données GraphTokenLockWallet avec l'adresse 0xA16081F360e3847006dB660bae1c6d1b2e17eC2A  GraphTokenLockWallet.create(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'))  // Affirmer que la source de données a été créée  assert.dataSourceCount('GraphTokenLockWallet', 1)  // Ajouter une deuxième source de données avec le contexte  let context = new DataSourceContext()  context.set('contextVal', Value.fromI32(325))  GraphTokenLockWallet.createWithContext(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'), context)  // Affirmer qu'il y a maintenant 2 sources de données  assert.dataSourceCount('GraphTokenLockWallet', 2)  // Affirme qu'une source de données avec l'adresse "0xA16081F360e3847006dB660bae1c6d1b2e17eC2B" a été créée.  // Gardez à l'esprit que le type `Address` est transformé en minuscules lorsqu'il est décodé, vous devez donc passer l'adresse en minuscules lorsque vous affirmez qu'elle existe.  assert.dataSourceExists('GraphTokenLockWallet', '0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'.toLowerCase())  logDataSources('GraphTokenLockWallet')})
Exemple de sortie logDataSource
🛠  {  "0xa16081f360e3847006db660bae1c6d1b2e17ec2a": {    "kind": "ethereum/contract",    "name": "GraphTokenLockWallet",    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2a",    "context": null  },  "0xa16081f360e3847006db660bae1c6d1b2e17ec2b": {    "kind": "ethereum/contract",    "name": "GraphTokenLockWallet",    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2b",    "context": {      "contextVal": {        "type": "Int",        "data": 325      }    }  }

Test des modèles file/ipfs

De même que pour les sources de données dynamiques de contrat, les utilisateurs peuvent tester les fichiers sources de données et leurs gestionnaires

Exemple subgraph.yaml
...templates: - kind: file/ipfs    name: GraphTokenLockMetadata    network: mainnet    mapping:      kind: ethereum/events      apiVersion: 0.0.9      language: wasm/assemblyscript      file: ./src/token-lock-wallet.ts      handler: handleMetadata      entities:        - TokenLockMetadata      abis:        - name: GraphTokenLockWallet          file: ./abis/GraphTokenLockWallet.json
Exemple schema.graphql
"""Portefeuilles de verrouillage de jetons qui contiennent des GRT verrouillés"""type TokenLockMetadata @entity {  "L'adresse du portefeuille de blocage des jetons"  id: ID!  "Heure de début du calendrier de sortie"  startTime: BigInt!  "Heure de fin du calendrier de sortie""  endTime: BigInt!  "Nombre de périodes entre l'heure de début et l'heure de fin"  periods: BigInt!  "Heure à laquelle commence la sortie"  releaseStartTime: BigInt!}
Exemple metadata.json
{  "startTime": 1,  "endTime": 1,  "periods": 1,  "releaseStartTime": 1}
Exemple de gestionnaire
export function handleMetadata(content: Bytes): void {  // dataSource.stringParams() renvoie le CID du fichier de la source de données  // stringParam() sera simulé dans le test du gestionnaire  // pour plus d'informations https://thegraph.com/docs/en/developing/creating-a-subgraph/#create-a-new-handler-to-process-files  let tokenMetadata = new TokenLockMetadata(dataSource.stringParam())  const value = json.fromBytes(content).toObject()  if (value) {    const startTime = value.get('startTime')    const endTime = value.get('endTime')    const periods = value.get('periods')    const releaseStartTime = value.get('releaseStartTime')    if (startTime && endTime && periods && releaseStartTime) {      tokenMetadata.startTime = startTime.toBigInt()      tokenMetadata.endTime = endTime.toBigInt()      tokenMetadata.periods = periods.toBigInt()      tokenMetadata.releaseStartTime = releaseStartTime.toBigInt()    }    tokenMetadata.save()  }}
Exemple de test
import { assert, test, dataSourceMock, readFile } from 'matchstick-as'import { Address, BigInt, Bytes, DataSourceContext, ipfs, json, store, Value } from '@graphprotocol/graph-ts'import { handleMetadata } from '../../src/token-lock-wallet'import { TokenLockMetadata } from '../../generated/schema'import { GraphTokenLockMetadata } from '../../generated/templates'test('exemple de création d'une dataSource file/ipfs', () => {  // Générer le CID de la source de données à partir du fichier ipfsHash + chemin ipfs  // Par exemple QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm/example.json  const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'  const CID = `${ipfshash}/example.json`  // Créer une nouvelle dataSource en utilisant le CID généré  GraphTokenLockMetadata.create(CID)  // Affirmer que la dataSource a été créée  assert.dataSourceCount('GraphTokenLockMetadata', 1)  assert.dataSourceExists('GraphTokenLockMetadata', CID)  logDataSources('GraphTokenLockMetadata')  // Nous devons maintenant simuler les métadonnées de la dataSource et plus particulièrement dataSource.stringParam()  // dataSource.stringParams utilise en fait la valeur de dataSource.address(), nous allons donc simuler l'adresse en utilisant dataSourceMock de matchstick-as  // Nous allons d'abord réinitialiser les valeurs, puis utiliser dataSourceMock.setAddress() pour définir le CID.  dataSourceMock.resetValues()  dataSourceMock.setAddress(CID)  // Nous devons maintenant générer les octets à transmettre au gestionnaire de la dataSource.  // Pour ce cas, nous avons introduit une nouvelle fonction readFile, qui lit un json local et renvoie le contenu sous forme d'octets  const content = readFile(`path/to/metadata.json`)  handleMetadata(content)  // Maintenant nous allons tester si un TokenLockMetadata a été créé  const metadata = TokenLockMetadata.load(CID)  assert.bigIntEquals(metadata !.endTime, BigInt.fromI32(1))  assert.bigIntEquals(metadata !.periods, BigInt.fromI32(1))  assert.bigIntEquals(metadata !.releaseStartTime, BigInt.fromI32(1))  assert.bigIntEquals(metadata !.startTime, BigInt.fromI32(1))})

Couverture de test

En utilisant Matchstick, les développeurs de Subgraph peuvent exécuter un script qui calculera la couverture des tests unitaires écrits.

L’outil de couverture des tests prend les binaires de test compilés wasm et les convertit en fichiers wat, qui peuvent alors être facilement inspectés pour voir si les gestionnaires définis dans subgraph.yaml ont été appelés ou non. Comme la couverture du code (et les tests dans leur ensemble) n’en est qu’à ses débuts en AssemblyScript et WebAssembly, Matchstick ne peut pas vérifier la couverture des branches. Au lieu de cela, nous nous appuyons sur l’affirmation que si un gestionnaire donné a été appelé, l’événement/la fonction correspondant(e) a été correctement simulé(e).

Prérequis

Pour utiliser la fonctionnalité de couverture des tests fournie dans Matchstick, il y a quelques éléments à préparer à l’avance :

Exportez vos gestionnaires

Pour que Matchstick puisse vérifier quels handlers sont exécutés, ces handlers doivent être exportés depuis le fichier de test. Ainsi, dans notre exemple, dans notre fichier gravity.test.ts, nous avons importé le gestionnaire suivant :

importez { handleNewGravatar } from '../../src/gravity'

Pour que cette fonction soit visible (pour qu’elle soit incluse dans le fichier wat par nom), nous devons également l’exporter, comme ceci :

exportez { handleNewGravatar }

Usage

Une fois tout configuré, pour exécuter l’outil de couverture de test, exécutez simplement :

graph test -- -c

Vous pouvez également ajouter une commande coverage personnalisée à votre fichier package.json, comme ceci :

"scripts": {    /.../    "coverage": "graph test -- -c"  },

Cela exécutera l’outil de couverture et vous devriez voir quelque chose comme ceci dans le terminal :

$ graph test -cSkipping download/install step because binary already exists at /Users/petko/work/demo-subgraph/node_modules/binary-install-raw/bin/0.4.0___  ___      _       _         _   _      _|  \/  |     | |     | |       | | (_)    | || .  . | __ _| |_ ___| |__  ___| |_ _  ___| | __| |\/| |/ _` | __/ __| '_ \/ __| __| |/ __| |/ /| |  | | (_| | || (__| | | \__ \ |_| | (__|   <\_|  |_/\__,_|\__\___|_| |_|___/\__|_|\___|_|\_\Compiling...Running in coverage report mode. ️Reading generated test modules... 🔎️Generating coverage report 📝Handlers for source 'Gravity':Handler 'handleNewGravatar' is tested.Handler 'handleUpdatedGravatar' is not tested.Handler 'handleCreateGravatar' is tested.Test coverage: 66.7% (2/3 handlers).Handlers for source 'GraphTokenLockWallet':Handler 'handleTokensReleased' is not tested.Handler 'handleTokensWithdrawn' is not tested.Handler 'handleTokensRevoked' is not tested.Handler 'handleManagerUpdated' is not tested.Handler 'handleApproveTokenDestinations' is not tested.Handler 'handleRevokeTokenDestinations' is not tested.Test coverage: 0.0% (0/6 handlers).Global test coverage: 22.2% (2/9 handlers).

Durée d’exécution du test dans la sortie du journal

La sortie du journal inclut la durée de l’exécution du test. Voici un exemple :

[Thu, 31 Mar 2022 13:54:54 +0300] Program executed in: 42.270ms.

Erreurs de compilation courantes

Critique : impossible de créer WasmInstance à partir d’un module valide avec un contexte : importation inconnue : wasi_snapshot_preview1::fd_write n’a pas été défini

Ceci signifie que vous avez utilisé console.log dans votre code, qui n’est pas pris en charge par AssemblyScript. Veuillez considérer l’utilisation de Logging API

ERREUR TS2554 : attendu ? arguments, mais j’ai eu ?.

renvoyer le nouveau ethereum.Block (defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt) ;

dans ~lib/matchstick-as/assembly/defaults.ts(18,12)

ERREUR TS2554 : attendu ? arguments, mais j’ai eu ?.

renvoyer un nouveau ethereum.Transaction (defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt) ;

dans ~lib/matchstick-as/assembly/defaults.ts(24,12)

La non-concordance des arguments est causée par la non-concordance de graph-ts et de matchstick-as. La meilleure façon de résoudre des problèmes comme celui-ci est de tout mettre à jour vers la dernière version publiée.

Ressources supplémentaires

Pour toute aide supplémentaire, consultez cette démo Subgraph repo utilisant Matchstick⁠.

Réaction

Si vous avez des questions, des commentaires, des demandes de fonctionnalités ou si vous souhaitez simplement nous contacter, le meilleur endroit serait The Graph Discord où nous avons une chaîne dédiée à Matchstick, appelée 🔥| tests unitaires.