Plugin de test unitaire
Cliquez sur l’icône (double vérification) de la barre d’icônes pour accéder au plugin Solidity Unit Testing
.
Si vous n’avez pas utilisé ce plugin auparavant et que vous ne voyez pas l’icône double check
, vous devez l’activer depuis le gestionnaire de plugins Remix.
Allez dans le gestionnaire de plugins en cliquant sur l’icône (plug) et activez le plugin Solidity Unit Testing
.
L’icône double check
apparaît alors sur la barre d’icônes de gauche. En cliquant sur l’icône, le plugin sera chargé dans le panneau latéral.
Alternativement, sélectionnez simplement l’environnement Solidity
depuis l’onglet Home
de l’IDE Remix. Cela activera le plugin Solidity Unit Testing
ainsi que les plugins Solidity Compiler
, Deploy & Run Transactions
et Solidity Static Analysis
.
Après un chargement réussi, le plugin ressemble à ceci :
Répertoire des tests
Le plugin vous demande de fournir un répertoire qui sera votre espace de travail uniquement pour ce plugin. Pour sélectionner le répertoire, dès que vous ajoutez /
au chemin, il affiche les options possibles.
Une fois sélectionné, ce répertoire sera utilisé pour charger les fichiers de test et pour stocker les fichiers de test nouvellement générés.
Le répertoire de test par défaut est browser/tests
.
Générer
Sélectionnez un fichier solidity que vous voulez tester et cliquez sur le bouton Générer
. Un fichier de test dédié au fichier sélectionné sera généré dans le répertoire de test.
Si aucun fichier n’est sélectionné, il créera quand même un fichier avec le nom générique newFile_test.sol
.
Ce dossier contient suffisamment d’informations pour vous permettre de mieux comprendre l’élaboration de tests pour un contrat.
Le fichier générique se présente comme suit :
pragma solidity >=0.4.22 <0.8.0;
import "remix_tests.sol"; // this import is automatically injected by Remix.
import "remix_accounts.sol";
// Import here the file to test.
// File name has to end with '_test.sol', this file can contain more than one testSuite contracts
contract testSuite {
/// 'beforeAll' runs before all other tests
/// More special functions are: 'beforeEach', 'beforeAll', 'afterEach' & 'afterAll'
function beforeAll() public {
// Here should instantiate tested contract
Assert.equal(uint(1), uint(1), "1 should be equal to 1");
}
function checkSuccess() public {
// Use 'Assert' to test the contract,
// See documentation: https://remix-ide.readthedocs.io/en/latest/assert_library.html
Assert.equal(uint(2), uint(2), "2 should be equal to 2");
Assert.notEqual(uint(2), uint(3), "2 should not be equal to 3");
}
function checkSuccess2() public pure returns (bool) {
// Use the return value (true or false) to test the contract
return true;
}
function checkFailure() public {
Assert.equal(uint(1), uint(2), "1 is not equal to 2");
}
/// Custom Transaction Context
/// See more: https://remix-ide.readthedocs.io/en/latest/unittesting.html#customization
/// #sender: account-1
/// #value: 100
function checkSenderAndValue() public payable {
// account index varies 0-9, value is in wei
Assert.equal(msg.sender, TestsAccounts.getAccount(1), "Invalid sender");
Assert.equal(msg.value, 100, "Invalid value");
}
}
Rédiger des tests
Rédigez suffisamment de tests unitaires pour vous assurer que votre contrat fonctionne comme prévu dans différents scénarios.
Remix injecte une bibliothèque intégrée assert
qui peut être utilisée pour les tests. Vous pouvez consulter la documentation de la bibliothèque here.
En outre, Remix permet d’utiliser certaines fonctions spéciales dans le fichier de test afin de rendre les tests plus structurés. Ces fonctions sont les suivantes :
beforeEach()
- S’exécute avant chaque testbeforeAll()
- S’exécute avant tous les testsafterEach()
- S’exécute après chaque testafterAll()
- S’exécute après tous les tests
Pour commencer, consultez cet exemple simple.
Exécuter
Une fois que vous avez fini d’écrire les tests, sélectionnez le(s) fichier(s) et cliquez sur Run
pour exécuter les tests. L’exécution se fera dans un environnement séparé. Après avoir terminé l’exécution d’un fichier, un résumé du test sera affiché comme ci-dessous :
Pour les tests qui ont échoué, il y aura plus de détails d’assertion pour analyser le problème. Si vous cliquez sur un test qui a échoué, la ligne de code correspondante sera mise en évidence dans l’éditeur.
Arrêter
Si vous avez sélectionné plusieurs fichiers pour exécuter les tests et que vous souhaitez arrêter l’exécution, cliquez sur le bouton « Stop ». L’exécution s’arrêtera après avoir exécuté les tests pour le fichier en cours.
Personnalisation
Remix offre aux utilisateurs différents types de personnalisation pour tester correctement un contrat.
1. Contexte de compilation personnalisé
Solidity Unit Testing
fait référence au plugin Solidity Compiler
pour la configuration du compilateur. Configurez Compiler
, EVM Version
, Enable Optimization
& runs
dans le plugin Solidity Compiler
et ceci sera utilisé dans le plugin Solidity Unit Testing
pour la compilation des contrats avant de lancer les tests unitaires.
2. Contexte de transaction personnalisé
Pour interagir avec la méthode d’un contrat, les principaux paramètres d’une transaction sont l’adresse from
, value
et gas
. Généralement, le comportement d’une méthode est testé avec différentes valeurs de ces paramètres.
On peut saisir des valeurs personnalisées pour msg.sender
et msg.value
de la transaction en utilisant les commentaires NatSpec, comme par exemple :
/// #sender: account-0
/// #value: 10
function checkSenderIs0AndValueis10 () public payable {
Assert.equal(msg.sender, TestsAccounts.getAccount(0), "wrong sender in checkSenderIs0AndValueis10");
Assert.equal(msg.value, 10, "wrong value in checkSenderIs0AndValueis10");
}
Mode d’emploi :
Les paramètres doivent être définis dans la NatSpec de la méthode
Chaque clé de paramètre doit être préfixée par un hash (#) et se terminer par deux points après un espace (** : **) comme
#sender :
&#value :
Pour l’instant, la personnalisation n’est disponible que pour les paramètres
sender
etvalue
L’expéditeur est l’adresse
from
d’une transaction à laquelle on accède en utilisantmsg.sender
à l’intérieur d’une méthode de contrat. Il doit être défini dans un format fixe comme « account-<account_index> ».<account_index>
varie de0-2
avant la sortie de la version 0.10.0 de remix-ide et de0-9
après.remix_accounts.sol
doit être importé dans votre fichier de test pour utiliser lesender
personnaliséLa valeur est la
valeur
envoyée avec une transaction danswei
et à laquelle on accède en utilisantmsg.value
à l’intérieur d’une méthode de contrat. Il doit s’agir d’un nombre.
En ce qui concerne gas
, Remix estime en interne le gaz nécessaire pour chaque transaction. Toujours si le déploiement d’un contrat échoue avec l’erreur Out-of-Gas
, il essaie de le redéployer en doublant le gaz. Un déploiement qui échoue avec un gaz double affichera l’erreur suivante : le déploiement du contrat a échoué après avoir essayé deux fois : le code du contrat n'a pas pu être stocké, veuillez vérifier votre limite de gaz
.
Various test examples can be seen in examples section.
Points à retenir
Un contrat de test ne peut pas avoir de méthode avec des paramètres. Si vous avez une telle méthode, vous obtiendrez l’erreur suivante :
La méthode 'nom de la méthode' ne peut pas avoir de paramètres à l'intérieur d'un contrat de test
Le nombre de comptes de test est de
3
avant la sortie de la version 0.10.0 de remix-ide et de10
après.Bien qu’un fichier de test qui importe
remix_accounts.sol
puisse ne pas compiler avec succès avec le pluginSolidity Compiler
, ne vous inquiétez pas, cela n’aura aucune incidence sur son succès avec le pluginSolidity Unit Testing
.