Protactor ou Selenium

Bonjour,
je dois choisir entre deux technos pour faire des tests de non regression : protactor ou selenium. Lequel choisir ?
j'utilise Angularjs pour la partie interface graphique de mon application

- protactor me semble tout indiqué mais il semble que les tests ne peuvent pas interagir avec le coté serveur ( c'est à dire que je sois obligé de faire des requêtes mockés plutôt que des requêtes normale). En effet dans le turoriel Angularjs les auteurs disent :

Citation:

---

•Request $httpBackend service to be injected into our beforeEach function. This is a mock version of the service that in a production environment facilitates all XHR and JSONP requests. The mock version of this service allows you to write tests without having to deal with native APIs and the global state associated with them — both of which make testing a nightmare

---

Donc est il possible de faire des tests protactor dans les conditions réelles avec des requêtes normales qui interagie avec le coté serveur ?

D'autre part ces tests devraient utiliser quel type de données en base de donnée ? faut-il monter une base de donnée dédiée spécialement aux tests protactor ou au tests selenium ?

D'autre part, est-il possible d'intégrer ces tests (protactor ou selenium) dans un environnement d'intégration comme Jenkins de manière automatique ?

Enfin quel est la techno la plus appropriée (protactor ou selenium) qui réunisse toutes ces conditions ?

Protractor ou Selenium servent à faire des tests end to end (e2e), c'est à dire à tester des scénarios fonctionnels.
Le principe c'est de lancer l'ensemble de la stack dans un environnement le plus proche possible de la production pour vérifier que tout va bien.

Protractor est tout indiqué du fait de son intégration à AngularJS (via les generators notamment). Pour info Protractor est en fait un wrapper de selenium, donc on peut dire que utiliser protractor c'est en fait utiliser selenium.

Citation:

---

- protactor me semble tout indiqué mais il semble que les tests ne peuvent pas interagir avec le coté serveur ( c'est à dire que je sois obligé de faire des requêtes mockés plutôt que des requêtes normale).

---

Non. Quand tu lances des tests e2e tu lances ton frontend, tu ne mockes rien du tout. Ce que vont faire des tests e2e c'est de charger une url, cliquer sur un bouton, vérifier que telle ou telle info est bien présente sur ta page etc ...

$httpBackend s'utilise dans les tests unitaires pour mocker le back.

Citation:

---

Donc est il possible de faire des tests protactor dans les conditions réelles avec des requêtes normales qui interagie avec le coté serveur ?

---

Oui, tout dépend de ton build. Tu peux parfaitement mocker ton back également en utilisant un outil comme api-mocker.

Citation:

---

D'autre part ces tests devraient utiliser quel type de données en base de donnée ? faut-il monter une base de donnée dédiée spécialement aux tests protactor ou au tests selenium ?

---

Généralement tu as une base de recette dédiée oui. Ca concerne le backend.
Tu vas avoir différentes installations disponibles de ton back accessibles via différentes url, et il faut configurer ton build de ton front pour taper sur ces urls selon ce que tu veux faire.
Par exemple :
- http://dev.domain.tld/projet/api/version/service (pour le développement si tu ne mockes pas le back)
- http://int.domain.tld/projet/api/version/service (pour l'intégration)
- http://recette.domain.tld/projet/api/version/service (pour la recette)
- http://prod.domain.tld/projet/api/version/service (pour la production)

Citation:

---

D'autre part, est-il possible d'intégrer ces tests (protactor ou selenium) dans un environnement d'intégration comme Jenkins de manière automatique ?

---

Oui.

Citation:

---

Enfin quel est la techno la plus appropriée (protactor ou selenium) qui réunisse toutes ces conditions ?

---

Protractor, c'est développé en collaboration avec l'équipe qui développe AngularJS et ça encapsule Selenium.
Ca permet aussi d'utiliser la même librairie de tests que pour les TU (Jasmine par exemple).
Et c'est souvent intégré dans les generateurs d'applications yeoman.

Hello,

Citation:

---

Envoyé par Marco46

Non. Quand tu lances des tests e2e tu lances ton frontend, tu ne mockes rien du tout.

---

+1 et Je suis ok avec à peu près tout mais dans des tests e2e, on peut mocker la partie backend justement.
Ce qui m'intéresse, c'est bien la partie front. Je crée des tests d'intégration mais seulement pour le front. Si en réalité, le front et le back sont indépendants, je pense qu'ils doivent l'être aussi dans des tests d'intégration.
On considère, en effet, que ce sont deux applications différentes... parce que le serveur peut être développé d'une certaine manière et en java et puis quelques mois ou quelques années après, je décide de le refactorer en F# alors que le code côté front ne change pas... Dans ce cas, les tests front doivent toujours être verts.

Si tout est OK côté front, mon test d'intégration doit passer. C'est le test côté serveur qui doit échouer. Et s'il y a un bug coté serveur, ce n'est pas à l'application front qui doit lever une erreur.
Autre point, l'application serveur peut aussi être une application tierce. Dans ce cas, je dois absolument pas faire les vrais appels rest.

Arrete moi si je dis des bêtises mais c'est pareil quand il s'agit d'application java classiques. Dans les tests Selenium, même si on mock pas la couche métier, on peut très bien mocker la couche DAO et du coup, on ne tappe pas sur une base réelle.
Il existe d'ailleurs des projets sur github permettant le mock des appels http dans les tests e2e d'AngularJS. On teste tout mais arrivé à l'appel http, on le mock... Je pense que c'est cohérent.

Bonjour Slim et Marco46,

mon but est de tester mon application dans son ensemble (partie front-end et back-end ensemble), dans des conditions réelles d'utilisation, donc à priori, j'essaierai d'utiliser protactor sans mocker les requêtes http. Normalement les technos ne devraientt pas changer. Mais mon avis peut changer, il faut que j'en parle aux autres membres de mon équipe. Je reviendrais vers vous car j'essaye de faire un pock. En attendant, pour utiliser protactor dans Eclipse, j'ai vu qu'il existe un plugin TERN


Ma première étape est d'utiliser protactor en environnement de dev
Mon application est divisée en plusieurs modules

- un module app-web pour tout ce qui concerne la partie front-end ( fichiers HTML, JAVASCRIPT(AngularJs), CSS)
- un module app-service pour tout ce qui concerne la partie controller (qui recoit les requêtes, ce sont des EJB REST)
- un module app-business pour tout ce qui concerne la partie métier (ce sont des EJB)
- un module app-model pour tout ce qui concerne la couche persistence

Ce sont tous des projets MAVEN avec des dépendances les uns avec les autres avec aussi une dépendance vers un projet parent

j'ai essayé de simuler mon projet app-web de la manière suivante (qui est à l'origine, je rapelle un projet MAVEN). Pour la partie test qui n'existe pas encore, j'ai créé un répertoire test pour mes test unitaires (sous dossier unit) et mes tests de non régression (que je peux appeler tests fonctionnels, n'est ce pas ?) (sous le dossier e2e). Le reste simule grosso modo la structure que j'ai actuellement
Pièce jointe 190941

J'ai installé le plugin TERN

Seulement, lorsque je dois faire un convert to TERN Project, je ne sais pas si je pourrais toujours utiliser mon projet app-web comme un projet MAVEN qui va toujours fonctionner avec les autres projets et remplir sa tache de front-end et si cela ne vas pas foutre le bazar dans mon projet global (https://github.com/angelozerr/tern.j...rn-Eclipse-IDE)
Pièce jointe 190938

D'autre part si j'ai bien compris ce que m'a dit Marco46, il faudrait que mes tests e2e tapent sur mon environnement de test (http://recette.domain.tld/projet/api/version/service). Est ce que pour taper sur cet environnement, il faut que je le fasse directement dans le code de mes tests e2e ?

Code:

---

1 2 3 4

beforeEach(function() { browser.get('http://recette.domain.tld/projet/api/version/service/login.html'); // en admettant que c'est l'url de ma page de login, base de tous mes tests });

---

Re bonjour,

j'ai navigué sur la documentation de TERN et c'est plutôt décevant. Je pensais que ça permettait, sous Eclipse, de lancer les test unitaires avec Karma et les tests e2e avec protactor avec possibilité de debug, mais il semble que ça ne fournisse seulement que l'autocomplétion

Citation:

---

Envoyé par slim

Arrete moi si je dis des bêtises mais c'est pareil quand il s'agit d'application java classiques. Dans les tests Selenium, même si on mock pas la couche métier, on peut très bien mocker la couche DAO et du coup, on ne tappe pas sur une base réelle.
Il existe d'ailleurs des projets sur github permettant le mock des appels http dans les tests e2e d'AngularJS. On teste tout mais arrivé à l'appel http, on le mock... Je pense que c'est cohérent.

---

J'aime pas trop l'idée de mocker du code sur un test e2e, pour moi tu dois être en dehors de la boite que tu testes et ne pas y toucher. C'est pour ça que je vais simuler un back via le mal nommé api-mocker.

Mais sinon oui ça a du sens de faire des tests e2e avec un fake backend puis de tout rejouer avec un vrai.

@flamant

Connais pas TERN. Eclipse n'est plus un bon EDI, surtout pour AngularJS. Essayes Webstorm c'est beaucoup plus adapté :)

Tu devrais traiter ton projet front comme une application complètement décorrélée de ton back. Elle doit avoir son propre processus de livraison, son propre versionning, son propre changelog, etc ...

Citation:

---

D'autre part si j'ai bien compris ce que m'a dit Marco46, il faudrait que mes tests e2e tapent sur mon environnement de test (http://recette.domain.tld/projet/api/version/service). Est ce que pour taper sur cet environnement, il faut que je le fasse directement dans le code de mes tests e2e ?

---

Non ce que je veux dire c'est que les calls de webservices dans ta webapp doivent taper sur une url différente de celle que tu utiliserais en prod. Généralement on fait cette config au build de l'application.

Bonjour,

J'arrive un peu tard, mais voici mes réponses/remarques sur le sujet tern.java

Citation:

---

Seulement, lorsque je dois faire un convert to TERN Project, je ne sais pas si je pourrais toujours utiliser mon projet app-web comme un projet MAVEN qui va toujours fonctionner avec les autres projets et remplir sa tache de front-end et si cela ne vas pas foutre le bazar dans mon projet global

---

Tu n'a rien à craindre. "Convert to Tern Project", te créé just eun petit fichier ".tern-project" dans ton projet et c'est tout. Si tu fais de l'angular, je te conseille d'installer AngularJS Eclipse qui est basé sur tern.java. Ca te permet de bénéficier :

• de la completion, validation, navigation dans les pages HTML (completion sur les attributs ng-*, les modules directives, controller, model $scope, etc). Voir https://github.com/angelozerr/angula.../HTML-Features
• de l' Explorer Angular qui t'affiche dans une vue les modules, les controllers, etc de ton application.
• la vesrion 1.2.0 (qui n'est pas encore en release mais qui peut s'installer améliore cette vue et fournit aussi un dialogue de recherche des modules, controllers. Voir les démos sur https://github.com/angelozerr/angula...teworthy-1.2.0

Citation:

---

j'ai navigué sur la documentation de TERN et c'est plutôt décevant. Je pensais que ça permettait, sous Eclipse, de lancer les test unitaires avec Karma et les tests e2e avec protactor avec possibilité de debug, mais il semble que ça ne fournisse seulement que l'autocomplétion

---

Effectivement concernant protractor, ca fournit la complétion, validation sur toute l'API Jasmine+Protractor. Pour lancer les tests protractor en debug, il faut un bon débuggeur JavaScript Eclipse, ce qui n'est pas le cas aujourd'hui. MAIS il existe

• Webclispe mais je ne sais pas si la license est encore gratuite (moi je l'ai installé au début donc j'ai bénéficié de cette offre, ca a l'air de marcher encore)
• L'équipe du projet JSDT (projet Eclipse JavaScript en standard) est en train de travailler sur le sujet du debuggeur pour la prochaine version d'Eclipse Neon.

J'ai créé une issue pour lancer/debugger protractor via Eclipse sur https://github.com/angelozerr/angula...pse/issues/178

Citation:

---

Connais pas TERN. Eclipse n'est plus un bon EDI, surtout pour AngularJS. Essayes Webstorm c'est beaucoup plus adapté

---

En effet Webstorm (qui est payant) est aujourd'hui beaucoup plus avancé que Eclipse. Le projet JSDT a été longtemps mis de côté mais fort heureusement, IBM & RedHat (avec JBoss Tools) ont repris le flambeau pour améliorer considérablement JSDT et pouvoir aussi déléguer encore mieux qu'aujourd'hui l'inférence (completion, etc) à d'autres composant comme ternjs.

Mais @Mickael_Istria pourra mieux vous en parler que moi.

Angelo

Citation:

---

Connais pas TERN. Eclipse n'est plus un bon EDI,

---

Eclipse + Tern c'est quand meme pas si mal. Si tu ne connais pas, jette-s-y au moins un oeil.
Après, je concède volontiers que l'ensemble reste encore inférieur à WebStorm (pour l'instant...).

Le principal projet (Eclipse JSDT) a quand même touché le fond quand ses contributeurs initiaux l'ont abandonné, peu avant que JS deviennent super-hype, avec une nouvelle version d'ES tous les ans et un nouveau framework "le meilleur du monde forever" toutes les semaines. Bref, triste époque...
Cette époque est révolue. De gros efforts sont en cours dans JSDT qui sera en 2.0 dans la prochaine version d'Eclipse (Neon, juin 2016). Plusieurs personnes et organisations prennent part à cet effort, dont Angelo qui a posté plus tôt, et des grosses features comme le debugger seront très prochainement dans les milestones. Le parsing sera aussi retapé, Grunt et Gulp supportés, et bien d'autres...
Bref, pour Eclipse et JS, le pire est passé, le meilleur est à venir bientôt; en juin 2016 pour le grand public. En attendant, les plugins tern, Angular et autres d'Angelo sont ce qui se fait de mieux pour la version actuelle.

Merci beaucoup Mickael pour tes précisions.

J'ai bossé sur le support Protractor dans AngularJS Eclipse et si tu installes AngularJS Eclipse 1.2.0 (qui n'est pas encore en release) tu peux sélectionner ton fichier de configuration Protractor avec le menu Run/Debug Protractor.

Pièce jointe 198361

Par défaut, le Run fonctionne. Si tu veux debugguer, il faut installer un debugger JavaScript node

JSDT 2.0 devrait fournir un debugger JavaScript (Eclipse Neon). J'attends qu'il soit opérationnel pour l'intégrer dans AngularJS Eclipse.

Le Run/Debug Protractor est un premier jet, je pense qu'on peut encore l'améliorer. J'attends des retours, n'hésitez pas à créer des issues (en anglais si possible) pour améliorer le support Protractor dans Eclipse. Merci.

Angelo