Protractor: Prise en charge de l'ajout de modules fictifs aux applications Angular 2

@juliemr prévoyons -nous de prendre en charge mock pour angular 2 ? Si oui quand? Si nous utilisons le mode hybride, mock continuera-t-il à fonctionner entre-temps ?

@ jlin412 oui, éventuellement, mais cela nécessitera une enquête et une réflexion approfondie sur la façon dont cela fonctionne à la fois dans aot et non-aot. Si vous utilisez hybride, il continuera à fonctionner pour les bits ng1.

Tous les autres - veuillez utiliser la réponse emoji de github aux problèmes +1. L'ajout de commentaires rend difficile l'analyse des progrès réels. Je vais supprimer ces commentaires pour que ce soit lisible. Merci!

@juliemr Avons-nous un ETA sur la mise en œuvre simulée pour angular 2 ?
Aussi, y a-t-il une alternative que nous pouvons utiliser en attendant ?

DE : http://stackoverflow.com/questions/36354233/protractor-mocking-backend-with-angular2-on-api-request.

Il en va de même pour les packages http-backend-proxy et httpbackend.

Par conséquent, j'ai créé un environnement de test E2E en utilisant docker-compose, mais je pense que c'est une implémentation exagérée.

Avez-vous actuellement des bonnes pratiques ?

J'ai rencontré le même problème pour me moquer de mes appels backend. Comme nous utilisons le middleware connect pour exécuter notre application, j'ai créé un plugin qui vous permet de simuler votre requête http angulaire 1 et 2.

https://mdasberg.github.io/ng-apimock/

peut-être que vous pouvez l'utiliser.

Je ne suis pas sûr du machinisme par lequel faire cela, mais je pense que l'approche naïve pour installer des modules fictifs serait la suivante :

Protractor remplacerait en quelque sorte ces deux méthodes:

• platformBrowserDynamic().bootstrapModule
• platformBrowser().bootstrapModuleFactory

À leur place, il y aurait un simple wrapper qui construit un nouveau ngModule et fournit les modules que nous voulons simuler (vous trouverez ci-dessous un pseudo-code de ce à quoi il ressemblerait):

function bootstrapModuleOverride (moduleToBootstrap) {
  @NgModule({
    imports: [moduleToBootstrap],
    provide: ArrayOfMockModules,
    bootstrap: moduleToBootstrap.bootstrap
  })
  class moduleToBoostrapWrapper {}

  platformBrowserDynamic().bootstrapModule(moduleToBoostrapWrapper);
}

Avez-vous une idée d'une sortie prévue pour cette fonctionnalité ?

+1 pour cette fonctionnalité. Nous avons besoin de mocks dans les tests e2e dans les applications Angular 2+ !

Angular 2+ se développe, donc cette fonctionnalité devient assez urgente :)

Oui, c'est absolument crucial pour notre flux de travail en ce moment.

Nous sommes déjà à angular5 et toujours incapables de nous moquer de http dans les spécifications e2e 😕

( @tauil petit monde, hein ?)

Voici les utilisations courantes dont j'ai besoin pour addMockModule .

1) injecter des intercepteurs personnalisés.
https://angular.io/guide/http#writing -an-interceptor
exemple capturer l'activité http et écrire sur le disque à l'aide du rapporteur si le test échoue.

2) remplacer la fonctionnalité dans les services normalement pour se moquer des services de données tiers.

      .decorator(
          'xyzService',
          [
            '$q', '$delegate',
            ($q, $delegate) => {
              $delegate.isEnabled = () => true;
              return $delegate;
            }
            $delegate.getProfileDetail = () =>
                  $q.when({name: 'Tester 001', title: 'E2E Tester'});
          ])

Pour les services personnalisés : nous pourrions suivre l'approche du modèle httpclient. La mise en œuvre de (1) résoudrait potentiellement ce problème également.

3) pour accéder aux éléments internes des objets de page individuels (mais pas casher)
ng.probe($0)._debugInfo
rapporteur executeScript

Quand sera-t-il mis en place ?

Pourrait vraiment faire avec ça!

C'est une fonctionnalité incontournable, comment peut-elle avoir deux ans ? !

En guise de solution de contournement, vous pouvez utiliser jswiremock pour supprimer les appels back-end. J'ai rédigé quelques instructions ici : https://gist.github.com/jamescookie/f7b854226ca1e133d1b7b2798095b7f4

Une autre alternative est nock .
Il s'agit d'une bibliothèque universelle pour se moquer des requêtes HTTP, ne dépendant d'aucun framework.

Vous pouvez utiliser ng-apimock qui est déjà présent sur le site du rapporteur. Il y a un super article de blog à ce sujet ici

Vous pouvez l'utiliser pour les applications AngularJs et Angular

Cette fonctionnalité est suffisamment cruciale pour que je pense qu'elle devrait faire partie du rapporteur principal, même si ng-apimock vient d'être inclus dans les bibliothèques principales du rapporteur.

J'essaie d'approuver autant que possible, où en est cette fonctionnalité ? C'est un gros bloqueur en ce moment.

Sérieusement, le rapporteur vient-il d'être abandonné pour Angular ?

C'est donc en partie faisable sans aucune modification du rapporteur ou de l'angle aujourd'hui. Vous pouvez créer une configuration "simulée" pour ng serve qui servira un ensemble différent de modules. Cela devrait vous permettre d'effectuer des tests backend sans avoir besoin de serveurs dépendants en cours d'exécution et d'éviter d'avoir à implémenter la moquerie au niveau de la couche HTTP. J'ai créé un exemple de référentiel démontrant ceci ici : https://github.com/westonpace/angular-example-mock-services

Je décris également les étapes requises dans ma réponse à une question SO ici : https://stackoverflow.com/questions/39942118/how-to-inject-different-service-based-on-certain-build-environment-in-angular2 /51772549#51772549

Ce n'est pas aussi facile/personnalisable que dans Angular 1 (par exemple, vous ne pouvez pas ajouter différents services fictifs pour différents tests), mais une fois que l'échafaudage est opérationnel, ajouter et supprimer des services fictifs devrait être assez simple.

Résumé d'un moyen rapide - propre - sans bibliothèque de gérer cela ici :

https://stackoverflow.com/questions/36354233/protractor-mocking-backend-with-angular2-on-api-request/51834607#51834607

Y a-t-il une mise à jour à ce sujet ? @ jlin412 , vous avez dit que cela nécessiterait une enquête et une réflexion approfondie - avez-vous commencé ?

Y a-t-il une mise à jour à ce sujet ? @ jlin412 , vous avez dit que cela nécessiterait une enquête et une réflexion approfondie - avez-vous commencé ?

@katiesandford , je pense que l'approche détaillée ici s'adaptera à la plupart des situations de test dans cette configuration. Si ce n'est pas le cas, j'aimerais savoir quelles sont ces valeurs aberrantes afin que je puisse y penser pour les situations futures

@gabrieldoty Avec cette approche, vous pouvez vous moquer au niveau du service mais pas au niveau http si je comprends bien.
De plus, dans une approche de développement axée sur le comportement, vous voulez que vos simulations soient dynamiques. Différentes étapes de test configureraient différentes simulations. Cela semble difficile à réaliser avec cette configuration.

@gaeljw excellents points ! Je peux voir des façons plutôt maladroites de gérer les simulations dynamiques, mais il ne fait aucun doute qu'une solution dynamique serait préférable !

Mon application n'utilise qu'une seule classe dataservice pour gérer toutes les requêtes HTTP, il est donc assez facile d'échanger ce service. Mais ce n'est pas aussi universel qu'une véritable simulation http.

Merci pour ces pensées !

Des nouvelles à ce propos? Il semble que le développement de Protractor ne soit plus aussi actif...

les mises à jour?

Des modules moqueurs aideraient à contourner # 4300

Wow, ce billet a presque 4 ans maintenant ! Y a-t-il des mises à jour ?

Des nouvelles?