4
votes

Comment écrire un cas de test à l'aide de la fonction Jest for Yup.isValid?

J'essaie d'ajouter un test unitaire pour valider la fonction Yup.isValid , mais le cas de test après l'exécution montrant une erreur comme: Timeout - Le rappel Async n'a pas été appelé dans le délai spécifié par jasmine.DEFAULT_TIMEOUT_INTERVAL . Même si je modifie le délai minimum de jasmin, même erreur d'affichage. Ma fonction pour valider le schéma Yup est:

test("validate Schema",async () => {
    let catchFn = jest.fn();
    let data= someSampleData;
    //data is valid as per the schema
   await validationSchema(
        validationSchema,
        data
      )
      .then(res => {
       //My expected condition
      })
      .catch(catchFn);
  });

Mon cas de test est:

export const validateSchema= (
  validationSchema,
  data
) => {
  return new Promise(async (resolve, reject) => {
    await validationSchema
      isValid(data)
      .then(isFormValid => {
        //passing response to method
      })
      .catch(error => reject(error));
  });
};

Le cas de test ci-dessus ne va pas là où je peut mettre ma condition. La même erreur arrive que je l'ai mentionné. Comment puis-je résoudre ce problème?


2 commentaires

Comment avez-vous défini un délai d'expiration? Avez-vous vérifié combien de temps prend la promesse pour se résoudre? D'après ce que vous avez publié, c'est en attente. Le fait qu'il y ait Jasmine en cours d'utilisation suggère que vous utilisez l'ancienne version de Jest, les versions plus récentes ne dépendent pas de Jasmine. Y at-il une raison à cela?


@estus Je ne pense pas que ce soit un problème de versions. J'augmente le délai en ajoutant 9000 dans la fonction de test comme: test ("valider le schéma", async () => {}, 9000);


3 Réponses :


1
votes

validateSchema utilise l'anti-modèle de construction de promesse et montre l'une des raisons pour lesquelles il est considéré comme un anti-modèle, nouvelle promesse est une construction inutile qui est sujette à des erreurs humaines.

Le l'utilisation de async comme exécuteur de Promise est une erreur qui contribue à l'anti-modèle. L'exécuteur Promise ignore une promesse renvoyée par la fonction async . résoudre n'est jamais appelé, alors que .catch (error => rejet (erreur)) est sans opération. validateSchema renvoie une promesse rejetée ou en attente. Si la promesse en attente est renvoyée par un test, cela entraîne un délai d'expiration.

Il devrait être:

test("validate Schema",async () => {
   let data= someSampleData;
   await validateSchema(...);
   //My expected condition
});

Mélange attendre et des promesses crues sont rarement nécessaires. L'utilisation de la fonction factice dans catch dans le test entraînera des erreurs de suppression, ce qui est rarement un comportement souhaitable.

Le test peut être:

export const validateSchema= async (
  validationSchema,
  data
) => {
    await validationSchema;
    const isFormValid = isValid(data);
    await updateFormValidFlag(isFormValid, theFormName); // does it return a promise?
  });
};


4 commentaires

isFormValid renvoie toujours false dans le cas de test


Les raisons pour lesquelles cela pourrait arriver ne sont pas couvertes par la question. En ce qui concerne le problème de délai d'attente, c'est l'explication.


oui, vous avez raison, mais supprimer les promesses de la méthode ne résoudra pas notre problème, mais nous ne sommes toujours pas en mesure de tester les cas de test pour la fonction yup.isValid mentionnée dans le titre de la question.


On ne sait pas pourquoi il y a un problème avec isValid. La question ne contient pas stackoverflow.com/help/mcve . Si vous fournissez des données non valides, elles renverront false. Il n'y a pas de données ni de schéma dans la question. updateFormValidFlag n'est pas affiché. Notez également qu'il y a wait validationSchema (. Est-ce une faute de frappe, ne devrait-il pas être wait validateSchema (?



0
votes

Pour les grands schémas, il peut être intéressant d'utiliser l'api validateAt de yup pour passer un chemin pour valider, afin que les données de montage puissent être plus concises.

Les spécifications Jest pourraient ressembler à quelque chose comme:

  it("requires person's name", async () => {
    await expect(schema.validateAt('person.name', {})).rejects.toBeFalsy()
    await expect(schema.validateAt('person.name', {person: {name: "something"}})).resolves.toBeTruthy()

  }
await expect(schema.validateAt(path, fixture)).rejects.toBeTruthy()

Les tests unitaires sont intéressants, car il s'agit en grande partie de configuration, tester que les bibliothèques fonctionnent comme elles le disent peut être superflu. Cependant, cela semble utile pour tester des comportements de validation de schéma personnalisés plus complexes.


0 commentaires

0
votes

Juste un autre exemple, je vérifie principalement les vraies valeurs

it( 'should handle validating object', async () => {
  const result = await schema.isValid(myObject)
  expect( result ).toEqual( true )
} )


0 commentaires