npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@charlesgilles/bdd-generator

v1.2.1

Published

Les tests `jest-cucumber` sont parfois long à écrire, il faut d'abord définir les steps puis pour **chacun** des cas de test, écrie la fonction. Ce qui parfois double ou triple la taille du fichier. Ils doivent être écris à la main et peuvent provoquer de

Downloads

11

Readme

bdd-generator

Utilité

Les tests jest-cucumber sont parfois long à écrire, il faut d'abord définir les steps puis pour chacun des cas de test, écrie la fonction. Ce qui parfois double ou triple la taille du fichier. Ils doivent être écris à la main et peuvent provoquer des erreurs.

Avec ce package, nous pouvons écrire uniquement les steps.


Installation

Voici la commande pour installer le package npm i -D @charlesgilles/bdd-generator


Configuration

Si vous souhaitez modifier cela, il vous faudra créer un fichier bdd-generator.json. Voici les paramètres par défaut:

{
    "lang": "en",
    "steps": "./src/__features__",
    "features": "./src/__features__",
    "ignoreGenerationTag": "ignore-generation",
    "onlyGenerationTag": "only-generation",
    "ignoreExecutionTag": "ignore",
    "onlyExecutionTag": "only",
    "forceStepsRegeneration": false
}

Les champs du fichier de paramétrage sont optionnels si vous souhaitez modifier soit l'un soit l'autre ou les deux. Une erreur vous sera indiquée si l'un des path renseigné n'existe pas.

  • lang: La langue du package. Les valeurs possibles sont fr et en
  • steps: L'emplacement des fichiers .stepdefinitions.[tj]sx?
  • features: L'emplacement des fichiers .feature
  • ignoreGenerationTag: Le tag empéchant la génération du fichier steps correspondant. Le tag doit être au niveau de la Feature.
  • onlyGenerationTag: Le tag permettant de ne générer que les fichiers demandés. Le tag doit être au niveau de la Feature.
  • ignoreExecutionTag: Ajoute dans le fichier .steps généré l'indicateur qu'il faut ignorer l'exécution d'un test. Le tag doit être placé au niveau d'un Scenario
  • onlyExecutionTag: Ajoute dans le fichier .steps généré l'indicateur qu'il ne faut exécuter que les tests correspondant. Le tag doit être placé au niveau d'un Scenario
  • forceStepsRegeneration: Indique s'il faut regénéré en permanence les fichiers steps ou seulement lors de modifications

Utilisation

Les fichiers .feature

Les fichiers .feature sont les fichiers gherkin qui décrivent le comportement de votre application.

Exemple:

@utils
Feature: Calculatrice
En tant que mathématicien
Je veux pouvoir faire des opération basiques sur deux variables
Afin de vérifier que les calculs de Kévin ne sont pas bon

Background:
    Given La variable A est égale à "10"

Scenario Outline: <Operation> de deux nombres
    Given La variable B est égale à "-2"
    When J'effectue une "<Operation>"
    Then J'obtient le résultat "<Resultat>"

    Examples:
        | Operation      | Resultat |
        | addition       | 8        |
        | soustraction   | 12       |
        | multiplication | -20      |
        | division       | -5       |

Les fichiers .stepdefinitions.[jt]sx?

Ce sont des fichiers javascript qui contiennent les définitions des steps qui vont pouvoir être utilisées dans un ou plusieurs tests.

Exemples:

Fichier 1

import { defineStep, defineFileScopes, scenarioContext } from "@charlesgilles/bdd-generator";

// Les steps de ce fichier ne pourront être utilisées que si le fichier 
// .feature à le tag @utils
defineFileScopes([
    {
        tag: 'utils'
    }
]);

defineStep(["then"], /J'obtient le résultat "(.*)"/, (resultat) => {
  expect(scenarioContext.resultat).toBe(Number(resultat));
});

Fichier 2

import { defineStep, defineFileScopes, scenarioContext } from "@charlesgilles/bdd-generator";

// Les steps de ce fichier ne pourront être utilisées que si le fichier 
// .feature correspond à la feature indiquée
defineFileScopes([
    {
        feature: 'Calculatrice'
    }
]);

defineStep(["given"], /La variable A est égale à "(.*)"/, (a) => {
    scenarioContext.a = Number(a);
});

defineStep(["given"], /La variable B est égale à "(.*)"/, (b) => {
    scenarioContext.b = Number(b);;
});

defineStep(["when"], /J'effectue une "(.*)"/, (operation) => {
    switch (operation){
        case 'addition':
            scenarioContext.resultat = a + b;
            break;
        case 'soustraction':
            scenarioContext.resultat = a - b;
            break;
        case 'multiplication':
            scenarioContext.resultat = a * b;
            break;
        case 'division':
            scenarioContext.resultat = a / b;
            break;
        default:
            throw new Error(`L'opération "${operation}" n'existe pas`);
    }
});

Remarque: Ces fichiers supportent également le jsx.


Comment fonctionne le package

Comme énoncé dans l'introduction du package, nous allons écrire uniquement les steps correspondants aux fichiers .feature. Le package va se charger tout simplement de générer les fichiers .steps qui vont être exécutés par le framework de test.

Un fichier bdd-generator.hash.json est créé lors de la génération. il est utilisé en complément du paramètre forceStepsRegeneration. Il contient l'ensemble des hashs des fichiers .features et .stepdefinitions.


Comment utiliser le package

Les méthodes et objets disponibles

Les items suivants doivent être importées dans les fichiers stepdefinitions.[jt]sx? afin d'avoir l'inteliscence.

  • defineFileScopes permet de définir le scope de l'ensemble des steps du fichier. Un scope peut être le nom de la feature, le nom d'un scénario ou d'un tag.
defineFileScopes([
    {
        feature: 'Calculatrice'
    },
    {
        tag: 'test',
        scenario: 'Addition'
    }
]);

Avec l'exemple suivant, les steps du fichier pourront servir dans tout le fichier .feature dont le nom de la feature est Calculatrice ou dans les scénarios avec le tag test ET le nom de scénario Addition.

  • defineStep permet de définir une step. Les paramètres sont les suivants:

    1. Les blocs concernées, un tableau conposé de Given, When ou Then.
    2. Le match, la Regex ou la string correspondant à la step.
    3. Le callback: la fonction qui va être appelée lors du match.
    4. En paramètre optinnel, les scopes spécifiques à la step.
  • scenarioContext Le scenarioContext est la variable qui va contenir tout ce qui va être utilisé pendant l'exécution d'un Scénario, il transite entre les steps, d'où son nom.


La commande

Le package bdd-generator met à disposition une commande bdd-generate. dans votre fichier package.json, il faut renseigner dans la partie scripts l'utilisation de cette commande.

Exemple:

"scripts": {
    "test:generate": "bdd-generate",
    "test": "vitest",
    "vitest": "vitest --verbose"
},

Lors de l'exécution de la commande npm run test:generate, si vous avez bien écrit vos fichiers .feature et .stepdefinitions.[jt]sx?, vous aurez l'affichage suivant.

Logs cas nominal


Objectif

  • [X] Génération des fichiers steps à partir des fichiers .feature et .stepdefinitions.[jt]sx?
  • [X] Configuration du path des fichiers avec un fichier de configuration
  • [ ] Configuration du path des fichiers avec des paramètres à la commande bdd-generate
  • [X] Configuration des fichiers .feature à ignorer
  • [ ] Avoir une commande bdd-audit qui permettrait d'obtenir la liste des steps qui se ressemblent en terme de nom. et pourquoi pas de code
  • [X] Ajouter la possibilité d'avoir le package en Anglais et en Français
  • [X] Si des fichiers stepdefinition et feature n'ont pas bougé, alors pas besoin de regénérer les fichiers steps correspondants