50 votes

quelle est la différence réelle entre ng test et ng e2e ?

J'ai peur que quelqu'un ait fermé ma question mais je n'ai pas trouvé de question satisfaisante (peut-être parce que je suis très limité dans le monde d'Angular 2+ et que j'ai mal compris quelque chose).

D'après ce que j'ai pu comprendre après quelques Hello World réalisés et quelques démos YouTube regardées :

ng test :

  • vous écrivez votre test en utilisant le langage Jasmine
  • vous testez votre test avec de nombreux navigateurs disponibles en utilisant Karma
  • vous exécutez des tests unitaires ou intégrés
  • tous xxx.compnent.spec.ts et un rapport final similaire à celui de JUnit est affiché dans le navigateur.

ng e2e :

  • vous écrivez votre test en utilisant le langage Jasmine

  • vous testez votre test avec de nombreux navigateurs disponibles en utilisant Karma

  • vous écrivez vos tests en tenant compte de l'imbrication des événements utilisateur

    eg. page.navigateTo();
    page.getParagraphText()
      .then(msg => expect(msg).toEqual('Welcome to app!!'))
      .then(msg => expect(msg).toEqual('xxx'))
      .then(done, done.fail);
  • vous exécutez un test de bout en bout à l'aide de Protractor principalement après avoir déployé l'application, une sorte d'environnement de pré-production.

  • les tests sous le dossier e2e sont déclenchés et le résultat est imprimé dans la console de ligne de commande.

Théoriquement, la seconde est spécifique à l'approche de bout en bout, où l'objectif est de simuler un flux complet effectué par un utilisateur final.

J'espère que ce n'est pas le cas, mais je me demande ce qui se passe derrière la scène et qui les rend vraiment différents. Je ne veux pas comparer ce qui est le mieux, mais il est certain que j'ai raté quelque chose, car j'ai créé quelques tests en utilisant exactement la même idée que celle de l'utilisateur final et je l'ai déclenchée par le test ng.

Par exemple :

...

it('should display the modal when `create Paste` is clicked', () => {

    let createPasteButton = fixture.debugElement.query(By.css("button"));
    //create a spy on the createPaste  method
    spyOn(component,"createPaste").and.callThrough();

    //triggerEventHandler simulates a click event on the button object
    createPasteButton.triggerEventHandler('click',null);

    //spy checks whether the method was called
    expect(component.createPaste).toHaveBeenCalled();
    fixture.detectChanges();
    expect(component.showModal).toBeTruthy("showModal should now be true");
    expect(element.innerHTML).toContain("source-modal");
});

...

Je me souviens avoir lu quelque chose comme "protractor offre un comportement d'attente/de sommeil pendant l'exécution des tests" mais je ne vois pas où est la valeur de cet agrégat quand je vois les tests effectués sans que protractor soit capable de simuler un utilisateur final également. Tant que vous codez vos tests pour faire exactement le même flux fait par un utilisateur final, ce sera le même test e2e proposé sous le dossier e2e créé par Angular Cli.

Si mon étude m'a amené à comprendre correctement ce qui est écrit ci-dessus, alors la seule différence réelle est la façon dont moi, en tant que développeur, j'organise mes tests. Il n'y a rien de vraiment différent qui se passe derrière la scène.

Encore une fois, j'apprécierais de voir cette question comme une question de clarification à des fins didactiques : il n'y a aucune intention de comparer les cadres ici.

3 votes

Je crois que vous l'avez bien résumé et je ne vois pas comment vous en êtes arrivé à une conclusion comme celle-ci. Il n'y a rien de vraiment différent qui se passe derrière la scène . Ces derniers sont des tests boîte noire qui n'impliquent pas TestBed et sont effectués dans un environnement proche de la production. Les premiers sont l'inverse. Ce sont des choses différentes qui servent des objectifs différents. Si vous ne comprenez pas bien la différence entre les tests unitaires, d'intégration et e2e, vous trouverez de nombreuses réponses à vos questions sur ce sujet.

0 votes

Je suis tout à fait d'accord avec le commentaire d'Estus. J'ai ajouté une réponse pour fournir quelques éléments qui pourraient vous aider à comprendre l'ensemble.

67voto

Alex Beugnet Points 1974

Vous êtes sur la bonne voie pour comprendre tout cela.

  • Ng test (Jasmine + Angular Testing Utilities tests lancés via Karma) :

Vous utilisez le framework jasmine pour écrire vos tests, les définir en tant que suites et attendre des résultats que vous pouvez tester, mais l'essentiel est que vous utilisez en fait le lanceur karma pour exécuter les tests directement sur le navigateur. Ceci est normalement configuré dans l'application angulaire.

Cela signifie qu'un seul serveur exécute les tests et c'est tout. Vous testez avec vos propres valeurs et vérifiez que vos composants fonctionnent correctement.

L'objectif est de vérifier pour un seul composant (test unitaire) ou plusieurs modules / composants (tests d'intégration) qu'une seule fonction / un petit flux de travail fonctionne correctement comme prévu, sans effets secondaires.

  • Ng E2E (Jasmine + Protractor) :

Protractor est un cadre de test de bout en bout pour les applications Angular et AngularJS et AngularJS. Protractor exécute des tests contre votre application s'exécutant dans un navigateur réel, en interagissant avec elle comme le ferait un utilisateur.

Ici, les tests que vous avez écrits feront office d'utilisateur. Cela signifie que votre application s'exécute dans votre navigateur et qu'un autre programme exécutera les tests contre votre application, simulant ainsi une interaction avec l'utilisateur.

C'est très important, car cela signifie deux choses :

  1. Les tests unitaires et les tests d'intégration utilisent des données statiques et fictives pour exécuter les tests.
  2. Les tests Protractor utilisent des données réelles et effectuent les appels HTTP (ou autre) pour récupérer les données et les consommer/tester.

L'objectif de protractor est de valider un flux de travail opérationnel complet dans votre application. Par exemple, j'écrirai mon test unitaire pour mon composant de connexion, j'écrirai un test unitaire pour mon service de connexion, j'écrirai un test d'intégration pour l'ensemble de mon module et tout comportement que je dois tester et qui dépend de plusieurs composants / services. Une fois cela fait, j'écrirai plus tard un test complet de bout en bout qui validera l'ensemble de mon processus d'authentification dans mon application.

Gardez à l'esprit qu'il existe un ratio important concernant les tests, qui est très logique :

  • Les tests unitaires doivent représenter 70% de vos tests.
  • Les tests d'intégration devraient représenter 20% de vos tests.
  • Les tests E2E devraient représenter 10% de vos tests.

Pourquoi ? Parce que si vous avez testé correctement un grand nombre de vos composants, vous n'aurez pas besoin de les tester à nouveau dans vos tests de bout en bout.


Conclusion :

  • Ils fonctionnent différemment et leur objectif est de tester des choses différentes (fonction unitaire / flux complet).
  • Ils sont complémentaires, ce qui signifie que si vous ne réalisez que des tests unitaires / d'intégration, vous n'aurez jamais la garantie qu'un flux de travail fonctionnera de A à Z ; de même, si vous n'écrivez que des tests E2E, vous ne serez jamais en mesure de confirmer qu'il n'y a pas d'effets secondaires dans votre flux de travail.

N.B. : Soyez également conscient de ces points :

  • Jasmine, Karma et Protractor peuvent être personnalisés à volonté, de sorte que vous pouvez les faire sortir dans un fichier XML qui pourrait être traité par un travail Jenkins au lieu d'une ligne de commande qui n'est pas pratique.
  • Oui, vous pouvez écrire le même code pour les deux et tester effectivement la même chose, mais gardez à l'esprit que ce que vous voulez, c'est être efficace et écrire un code de test facile à maintenir. Les ratios dont j'ai parlé sont très importants.

J'espère que cela vous aidera.

1 votes

La différence pratique importante qui n'a pas été mentionnée est que les tests e2e sont censés être non contaminés, lents et exécutés relativement rarement. Alors que les tests unitaires sont rapides et exécutés à chaque occasion, avec un certain risque de contamination croisée. Ceci est garanti par le choix approprié des outils pour les deux scénarios (Protractor/Jasmine vs Karma/Jasmine/TestBed).

4 votes

Que voulez-vous dire par "les tests e2e devraient être non contaminés" et "avec un certain risque de contamination croisée" ? (Je ne peux même pas deviner ce que vous avez en tête)

0 votes

Je crois qu'il s'agit de ce que j'appelle les "effets de bord". Vous testez vos fonctions dans vos modules / composants pour vous assurer que le comportement souhaité est atteint. C'est la meilleure façon de s'assurer que le code que vous avez écrit n'a pas d'effet secondaire en dehors de son objectif. Puisque les tests E2E sont réalisés par la simulation de l'interaction de l'utilisateur, vous n'avez pas besoin de tester ce que le bouton doit faire puisque vous l'avez déjà testé avec les tests unitaires. Cela signifie qu'il n'y a pas d'effet secondaire possible s'il est testé au préalable correctement. Je suppose que c'est un peu vague, mais j'espère que cela vous aidera.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X