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.

If you haven’t used this plugin before and are not seeing the double check icon, you have to activate it from Remix plugin manager.

Allez dans le gestionnaire de plugins en cliquant sur l’icône (plug) et activez le plugin Solidity Unit Testing.

Now the double check icon will appear on the left side icon bar. Clicking on the icon will load the plugin in the side panel.

Alternatively, select Solidity environment from Remix IDE Home tab. This will activate Solidity Unit Testing plugin along with Solidity Compiler, Deploy & Run Transactions & Solidity Static Analysis plugins.

Après un chargement réussi, le plugin ressemble à ceci :

Répertoire des tests

Plugin asks you to provide a directory which will be your unit testing workspace (not to be confused with a Workspace in the File Explorer). To select directory, as soon as you add / to the path, it shows the possible options. [Rob Edit]

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

Select the Solidity file which you want to test and click on the Generate button. In the test directory, a test file will be created for your selected file.

If no file is selected, a generic test file named, newFile_test.sol will be created.

This file contains information about developing tests for a contract.

Below is an example of a generic test file:

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 injects a built-in assert library for testing. You can visit the library documentation here.

Additionally, Remix allows the usage of special functions in the test file to make testing more structural. They are:

  • beforeEach() - S’exécute avant chaque test

  • beforeAll() - S’exécute avant tous les tests

  • afterEach() - S’exécute après chaque test

  • afterAll() - S’exécute après tous les tests

Pour commencer, consultez cet exemple simple.

Exécuter

Once you are done with writing tests, select the file(s) and click on Run to execute the tests. The execution will run in a separate environment. After completing the execution of one file, a test summary will be shown:

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 :

  1. Les paramètres doivent être définis dans la NatSpec de la méthode

  2. 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 :

  3. Pour l’instant, la personnalisation n’est disponible que pour les paramètres sender et value

  4. L’expéditeur est l’adresse from d’une transaction à laquelle on accède en utilisant msg.sender à l’intérieur d’une méthode de contrat. Il doit être défini dans un format fixe comme « account-<account_index> ».

  5. <account_index> varie de 0-2 avant la sortie de la version 0.10.0 de remix-ide et de 0-9 après.

  6. remix_accounts.sol doit être importé dans votre fichier de test pour utiliser le sender personnalisé

  7. La valeur est la valeur envoyée avec une transaction dans wei et à laquelle on accède en utilisant msg.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 de 10 après.

  • Bien qu’un fichier de test qui importe remix_accounts.sol puisse ne pas compiler avec succès avec le plugin Solidity Compiler, ne vous inquiétez pas, cela n’aura aucune incidence sur son succès avec le plugin Solidity Unit Testing.