wp cli tests Télécharger - wp cli tests Téléchargement du code source

wp cli tests

Python

Version 4.3.5

Télécharger

wp-cli/wp-cli-tests

Cadre de test WP-CLI

Liens rapides : Utilisation de | Contribuer | Soutien

En utilisant

Pour utiliser le framework de test WP-CLI, vous devez suivre les étapes suivantes à partir du package auquel vous souhaitez les ajouter :

Ajoutez le cadre de test comme exigence de développement :
```
composer require --dev wp-cli/wp-cli-tests
```

Ajoutez les scripts de test requis au fichier composer.json :

 "scripts" : {
    "behat" : " run-behat-tests " ,
    "behat-rerun" : " rerun-behat-tests " ,
    "lint" : " run-linter-tests " ,
    "phpcs" : " run-phpcs-tests " ,
    "phpcbf" : " run-phpcbf-cleanup " ,
    "phpunit" : " run-php-unit-tests " ,
    "prepare-tests" : " install-package-tests " ,
    "test" : [
        " @lint " ,
        " @phpcs " ,
        " @phpunit " ,
        " @behat "
    ]
}

Vous pouvez bien entendu supprimer ceux dont vous n’avez pas besoin.

Ajoutez éventuellement un délai d'expiration de processus modifié au fichier composer.json pour vous assurer que les scripts peuvent s'exécuter jusqu'à ce que leur travail soit terminé :
```
 "config" : {
    "process-timeout" : 1800
},
```
Le timeout est exprimé en secondes.
Ajoutez éventuellement un fichier behat.yml à la racine du package avec le contenu suivant :
```
 default :
  suites :
    default :
      contexts :
        - WP_CLITestsContextFeatureContext
      paths :
        - features
```
Cela garantira que le système automatisé Behat fonctionne sur toutes les plateformes. Ceci est nécessaire sous Windows.

Ajoutez éventuellement un fichier phpcs.xml.dist à la racine du package pour activer le style de code et les vérifications des meilleures pratiques à l'aide de PHP_CodeSniffer.

Exemple d'un ensemble de règles personnalisé minimal basé sur les valeurs par défaut définies dans le framework de test WP-CLI :

<? xml version = " 1.0 " ?>
< ruleset name = " WP-CLI-PROJECT-NAME " >
< description >Custom ruleset for WP-CLI PROJECT NAME</ description >

    <!-- What to scan. -->
    < file >.</ file >

    <!-- Show progress. -->
    < arg value = " p " />

    <!-- Strip the filepaths down to the relevant bit. -->
    < arg name = " basepath " value = " ./ " />

    <!-- Check up to 8 files simultaneously. -->
    < arg name = " parallel " value = " 8 " />

    <!-- For help understanding the `testVersion` configuration setting:
         https://github.com/PHPCompatibility/PHPCompatibility#sniffing-your-code-for-compatibility-with-specific-php-versions -->
    < config name = " testVersion " value = " 5.4- " />

    <!-- Rules: Include the base ruleset for WP-CLI projects. -->
    < rule ref = " WP_CLI_CS " />

</ ruleset >

Toutes les autres options de configuration PHPCS sont bien entendu disponibles.

Mettez à jour vos dépendances de composer et régénérez votre chargeur automatique et vos dossiers binaires :
```
composer update
```

Vous êtes maintenant prêt à utiliser le framework de test depuis votre package.

Lancement des tests

Vous pouvez utiliser les commandes suivantes pour contrôler les tests :

composer prepare-tests - Configurez la base de données nécessaire à l'exécution des tests fonctionnels. Ceci n’est nécessaire qu’une seule fois.
composer test - Exécutez toutes les suites de tests.
composer lint - Exécutez uniquement la suite de tests de linting.
composer phpcs - Exécutez uniquement la suite de tests de code sniffer.
composer phpcbf - Exécutez uniquement le nettoyage du renifleur de code.
composer phpunit - Exécutez uniquement la suite de tests unitaires.
composer behat - Exécutez uniquement la suite de tests fonctionnels.

Contrôler ce qu'il faut tester

Pour envoyer un ou plusieurs arguments à l'un des outils de test, ajoutez un double tiret au début du ou des arguments. À titre d'exemple, voici comment exécuter les tests fonctionnels pour un fichier de fonctionnalités spécifique uniquement :

composer behat -- features/cli-info.feature

Il est nécessaire de faire précéder le double tiret car les arguments seraient autrement envoyés à Composer lui-même, et non à l'outil que Composer exécute.

Contrôler l'environnement de test

Version WordPress

Vous pouvez exécuter les tests sur une version spécifique de WordPress en définissant la variable d'environnement WP_VERSION .

Cette variable comprend toute version numérique, ainsi que les termes spéciaux latest et trunk .

Remarque : Cela s'applique uniquement aux tests fonctionnels Behat. Tous les autres tests ne chargent jamais WordPress.

Voici comment exécuter vos tests sur la dernière version du tronc de WordPress :

WP_VERSION=trunk composer behat

Binaire WP-CLI

Vous pouvez exécuter les tests sur un binaire WP-CLI spécifique, au lieu d'utiliser celui qui a été construit dans le dossier vendor/bin de votre projet.

Cela peut être utile pour exécuter vos tests sur une version Phar spécifique de WP_CLI.

Pour ce faire, vous pouvez définir la variable d'environnement WP_CLI_BIN_DIR pour qu'elle pointe vers un dossier contenant un binaire wp exécutable. Remarque : le binaire doit être nommé wp pour être correctement reconnu.

À titre d'exemple, voici comment exécuter vos tests sur une version spécifique de Phar que vous avez téléchargée.

 # Prepare the binary you've downloaded into the ~/wp-cli folder first.
mv ~ /wp-cli/wp-cli-1.2.0.phar ~ /wp-cli/wp
chmod +x ~ /wp-cli/wp

WP_CLI_BIN_DIR= ~ /wp-cli composer behat

Mise en place des tests dans Travis CI

Règles de base pour la mise en place du framework de test avec Travis CI :

composer prepare-tests doit être appelé une fois par environnement.
linting and sniffing sont une analyse statique, ils ne devraient donc pas dépendre d'un environnement spécifique. Vous ne devez le faire qu'une seule fois, dans le cadre d'une étape distincte, plutôt que par environnement.
composer behat || composer behat-rerun provoque l'exécution des tests Behat dans leur intégralité en premier, et dans le cas où leurs scénarios ont échoué, une deuxième exécution est effectuée avec uniquement les scénarios ayant échoué. Cela permet généralement de contourner des problèmes intermittents tels que des délais d'attente ou similaires.

Voici une configuration de base sur la façon dont vous pouvez configurer Travis CI pour qu'il fonctionne avec le framework de test (extrait) :

 install :
  - composer install
  - composer prepare-tests

script :
  - composer phpunit
  - composer behat || composer behat-rerun

jobs :
  include :
    - stage : sniff
      script :
        - composer lint
        - composer phpcs
      env : BUILD=sniff
    - stage : test
      php : 7.2
      env : WP_VERSION=latest
    - stage : test
      php : 7.2
      env : WP_VERSION=3.7.11
    - stage : test
      php : 7.2
      env : WP_VERSION=trunk

Version WP-CLI

Vous pouvez faire pointer les tests vers une version spécifique de WP-CLI via la constante WP_CLI_BIN_DIR :

WP_CLI_BIN_DIR= ~ /my-custom-wp-cli/bin composer behat

Version WordPress

Si vous souhaitez exécuter les tests de fonctionnalités sur une version spécifique de WordPress, vous pouvez utiliser la constante WP_VERSION :

WP_VERSION=4.2 composer behat

La constante WP_VERSION comprend également la latest et trunk comme versions cibles valides.

Les informations d'identification de la base de données

Par défaut, les tests sont exécutés dans une base de données nommée wp_cli_test avec l'utilisateur également nommé wp_cli_test avec le mot de passe password1 . Cela doit être configuré via la commande composer prepare-tests .

Les variables d'environnement suivantes peuvent être définies pour remplacer les informations d'identification par défaut de la base de données.

WP_CLI_TEST_DBHOST est l'hôte à utiliser et peut inclure un port, c'est-à-dire "127.0.0.1:33060" (par défaut "localhost")
WP_CLI_TEST_DBROOTUSER est l'utilisateur autorisé à administrer les bases de données et les utilisateurs (par défaut "root").
WP_CLI_TEST_DBROOTPASS est le mot de passe à utiliser pour l'utilisateur ci-dessus (par défaut, un mot de passe vide).
WP_CLI_TEST_DBNAME est la base de données sous laquelle les tests sont exécutés (par défaut "wp_cli_test").
WP_CLI_TEST_DBUSER est l'utilisateur sous lequel les tests sont exécutés (par défaut "wp_cli_test").
WP_CLI_TEST_DBPASS est le mot de passe à utiliser pour l'utilisateur ci-dessus (la valeur par défaut est "password1").
WP_CLI_TEST_DBTYPE est le type de moteur de base de données à utiliser, c'est-à-dire "sqlite" pour exécuter des tests sur SQLite au lieu de MySQL (par défaut "mysql").

Les variables d'environnement peuvent être définies pour l'ensemble de la session via la syntaxe suivante : export WP_CLI_TEST_DBNAME=custom_db .

Ils peuvent également être définis pour une seule exécution en les ajoutant avant la commande Behat : WP_CLI_TEST_DBNAME=custom_db composer behat .

Contribuer

Nous vous remercions d’avoir pris l’initiative de contribuer à ce projet.

La contribution ne se limite pas au code. Nous vous encourageons à contribuer de la manière qui correspond le mieux à vos capacités, en écrivant des didacticiels, en faisant une démonstration lors de votre rencontre locale, en aidant les autres utilisateurs avec leurs questions d'assistance ou en révisant notre documentation.

Pour une introduction plus approfondie, consultez le guide de contribution de WP-CLI. Ce package suit ces politiques et directives.

Signaler un bug

Vous pensez avoir trouvé un bug ? Nous serions ravis que vous nous aidiez à le réparer.

Avant de créer un nouveau problème, vous devez rechercher les problèmes existants pour voir s'il existe une résolution existante ou s'il a déjà été résolu dans une version plus récente.

Une fois que vous avez effectué quelques recherches et découvert qu'il n'y a pas de problème ouvert ou résolu pour votre bogue, veuillez créer un nouveau problème. Incluez autant de détails que possible et des étapes claires à reproduire si possible. Pour plus d’informations, consultez notre documentation sur les rapports de bogues.

Créer une pull request

Vous souhaitez contribuer à une nouvelle fonctionnalité ? Veuillez d'abord ouvrir un nouveau numéro pour déterminer si la fonctionnalité convient bien au projet.

Une fois que vous avez décidé de consacrer du temps à la réalisation de votre pull request, veuillez suivre nos directives pour créer une pull request afin de vous assurer que c'est une expérience agréable. Voir « Configuration » pour plus de détails spécifiques au travail sur ce package localement.