Un choc de simplification dans le developpement

C'est tout à fait vrai. Et fort heureusement, on est encore très loin de la démocratie à la Wikipédia.

Hello!

D'abord merci SpaceFox et Kje pour avoir vaillamment défendu mes outils, you da real mvp <3

Plus sérieusement, je suis content que ce qu'on a fait par rapport à npm a servit à quelque chose, et pour ce qui est du problème de la MEP, c'est effectivement un problème d'installation. (Pour faire court, avant npm 2.x.x, on était obligé d'installer certains outils globalement (gulp, bower) pour pouvoir leur passer des arguments… Qui dit global dit super-user, dit de la merde côté permissions. Du coup, comme on a corrigé ça, npm avait plus les droits sur le dossier dist/ et node_modules/… Ca devrait plus arriver )

Pour ce qui est des tests d'intégrations. J'y ai pensé justement y'a quelques temps, mais j'avais peur que l'installation de Sélénium (beurk, java) soit une "barrière" à ce que l'on mette en place ce type de solution (j'ai pas trouvé de solution suffisamment mature basée sur node ou python). Du coup, je vous propose… [roulements de tambours] SauceLabs

L'idée c'est qu'on peut lier SauceLabs à Travis pour qu'il l'utilise comme serveur Selenium. Avec ça, plus karmajs, plus un FW de tests (jasmine, …), on aurait lors des build travis les tests unitaires JS (qui arriveront quand on aura qq chose de + gros à tester, ce qui arrivera tôt ou tard), plus les tests d'intégrations lancés sur tous les navigateurs, mobiles comme desktop, de notre choix, avec des screenshot si on veux.

Les tests seraient en JS: ça me parait logique, puisque ça touche au DOM/front, et si une telle solution est mise en place, il y a de fortes chances pour qu'on en ai aussi, pour tester par exemple la lecture zen, ou plus tard (soyons fous), la mise à jour des notifications en temps réel ; donc autant utiliser le même système pour tout le monde ; je reste ouvert si vous me sortez une alternative sympa, que ce soit en Python, en C#, en Assembleur, ou en Brainfuck

En bonus, SauceLabs, qui est normalement payant, est gratos pour les projets OpenSource \o/

(c'était le petit quart d'heure pub )

Pour ce qui est de la rapidité de la QA, et du déploiement auto, je bosse avec gustavi sur une solution a base de Docker, de hooks github, et d'API OVH pour que chaque PR soit déployée dans la demi-heure vers pr-XXXX.zestedesavoir.com, en plus de la branche dev qui sera régulièrement aussi déployée quelque part (teasing, teasing… )

Si ça avance pas, c'est à cause du manque de temps ; pour ma part, je serais en vacances demain à 11h55, donc je risque d'être un peu plus présent à partir de la

Je ne suis pas vraiment d'accord sur les passages concernant les langages du message ci-dessus. Selenium est pilotable officiellement en Java, C#, Ruby, Python, Javascript (Node) ; et je ne vois où est la logique de faire les tests Selenium en JS, puisque le test lui-même n'interagit jamais directement avec le DOM/front mais uniquement avec Selenium, qui lui pilote le navigateur, qui lui interagit avec le DOM/front¹.

Subséquemment on peut donc se lancer dans des tests Selenium / SauceLabs dans n'importe quel langage – si on peut choisir un langage déjà utilisé dans le projet et facile à maintenir, c'est mieux.

Le "facile à maintenir" est important, parce que c'est des tests qu'il faut souvent mettre à jour – et qu'une modification lourde de l'arbre DOM de la page peut nécessiter de les mettre presque tous à jour…

Je dois avouer que pour le coup, j'ai pas encore pu vraiment mettre ça en place moi-même… J'ai déjà essayé de faire des tests End2End d'une app Angular avec Protractor (qui utilise selenium), et j'avais trouvé ça relativement intuitif et simple. En plus, comme c'est un FW de tests fait pour angular, la sélection d'éléments générés par Angular se faisait sans problèmes. L'avantage du machin, c'est qu'avec le même FW de tests (en l'occurence, Jasmine), j'avais mes tests unitaires et mes tests E2E

Pour te donner une idée de ce que ça donne un test avec WebDriverJS et Jasmine:

1
2
3
4
5
6
7
8

describe('basic test', function () {
    it('should be on correct page', function () {
        driver.get('http://example.com');
        driver.getTitle().then(function(title) {
            expect(title).toBe('Example');
        });
    });
});

J'vais me documenter sur Selenium en Python, si c'est la solution que vous préférez

Quasiment tous les langages ont rajouté la couche que tu décris au-dessus par dessus Selenium.

Plus personne aujourd'hui n'utilise l'API Selenium directement. Ca n'a rien à voir avec une manipulation du DOM, c'est juste l'approche que le framework a choisie pour wrapper l'API Selenium.

L'exemple que tu donnes est encore plus simple et élégant à écrire pour moi avec geb et Spock (chacun sa came )

Dans le cas de ZdS, il est logique de se servir de ces tests pour initier les gens au projet mais aussi éventuellement à Python. On s'était déjà posé la question (sur un topic ouvert par Nek je crois ?) et on avait regardé du côté de lettuce (NB : mais il paraît que c'est dla merde).

description d'une feature

1
2
3
4
5
6

Feature: Go to google

Scenario: Visit Google
  Given I go to "http://www.google.com/"
      When I fill in field with class "gsfi" with "testingbot"
      Then I should see "testingbot.com" within 2 second

EDIT : L'exemple type du truc qui devrait passer par un test d'intégration

J'y connais rien mais il me semble que des codes type ce que vient de présenter Javier, j'en ai vu dans les présentation des nouvelles feature de pycharm. La dernière version a dut intégrer le support de certains de ces framework. Puisqu'une grande partie de l'équipe de dev l'utilise (et qu'on a une licence pro pour tous les dev), peut être qu'un truc bien géré par pycharm arrangerait tout le monde ?

Après moi techniquement c'est comme les outils front, le plus important c'est avoir un truc qui fonctionne bien, je me fout un peu de la techno derrière. On a déjà des dépendances en python, JS, haskell (Pandoc), java (solr), … C'est pas ça qui doit nous bloquer.

Par contre on s'écarte peut être du sujet initial ? Je pense que ce genre de tests sont très important mais on pourrait faire un sujet a part, non ?

HS: Ce genre de discussion revient quand même souvent et de manière cyclique. Le jour ou elles arrêteront, alors ZdS sera mort.

Bon, pour revenir au sujet initial (déjà parce que je n'ai aucune expérience en tests d'intégration), je plussoie fortement ce qui a pu être dit en terme de donc: notre doc est éparpillée (entre SPHINX et github), fragmentaire et hautement incomplète (je sais plus qui a dit "y'a pas de commentaires dans le code et pas de doc générée en correspondance", eh bien je suis lourdement d'accord). Ceci étant, faut pas non plus être totalement négatif: au moins, il y a une doc, certes pas complète, mais les devs ont pris le temps d'écrire quelque chose. On doit donc être attentif à ça, mais il y a du mieux. Et bien entendu, on doit faire le pari d'une doc de code.

Par contre, je suis désolé de l'écrire aussi méchamment, mais j'ai essayé hier de me servir de la doc front, et objectivement, ça… Ne m'as aidé en rien du tout. Vraiment. Déjà, elle est pleine de TODO, et si j'ai bien suivi, il est impossible d'y contribuer directement en faisant une PR comme c'est le cas avec la doc' back. À l'époque, j'ai pu comprendre que ça avait ces raisons (y'a difficilement moyen de mettre du code HTML pur dans SPHINX était ce qui revenait, de tête), mais force est de constater que le choix qui a été fait n'est peut-être pas le meilleur non-plus (ceci dit, j'en ai pas de mieux à proposer, actuellement). D'autant quand on voit que la dernière contribution remonte à mi-septembre. De même, j'invite les gens du front à se rassembler une fois et à discuter un peu du "design" de ZdS: pour que tout le monde ne se mette pas à faire n'importe quoi, il faudrait selon moi qu'il soit écrit quelque part "telle et telle couleurs sont utilisées sur le site pour ça, ça et ça, elles sont définies là, et on peut les appeler comme ça dans le SCSS" et "le design du ZdS suis les recommandations du flat design, en particulier celle-là, celle-là et celle-là". Là ou je veux en venir, c'est qu'il faudrait à mon sens que cette doc ne décrive pas seulement ce qu'il y a dans les fichiers fronts, mais aussi les quelques règles qui devraient guider un contributeur pour qu'il ne rajoute pas des choses en jaune alors que ça n'as rien à y faire

EDIT: pourquoi personne ne parle jamais de la doc du JS du site ? Y'en a pas, et pareil, c'est gênant.

Le cas npm, franchement, ça va mieux. Vraiment. Je n'aime toujours pas cet outil parce qu'il a tendance à raconter ça vie à chaque fois qu'on le lance (avec force WARN et ERR, ce qui n'as jamais rien de rassurant), mais on s'y fait. Et il est déjà relativement plus stable qu'au début ou installer le front s'apparentait à une bataille. Ou peut être que c'est parce que ça fait plusieurs mois que je bosse avec (je rappelle que je ne bosse pas pour le front et que c'est uniquement pour faire de la QA) et que je m'y fait.

Parlons de QA, justement. Après bientôt un an de dev pour ZdS, ils y en a encore qui s'étonne que les petites PR sont mergées avant les grandes .... Non, sérieusement, des machins énormes comme la ZEP-03, feu la PR sur la désinscription ou des fonctionnalités avancées telles que celle proposées par Firm1 prennent du temps à être QA (et c'est souvent de la QA pas drôle, parce qu'elle est longue), demande dès lors plusieurs rebases (oui c'est pas drôle les rebases), plusieurs allez et retours entre le code, le dev', parfois même plusieurs devs et plusieurs personnes qui font de la QA, mais … C'est comme ça. Il faut en être conscient quand on développe des grosses fonctionnalités. Et en général, le retour de la communauté est positif et en redemande, donc ça les vaut. Du coup, dès qu'un machin est trop important, pour moi, il faudrait :

• Idéalement, en faire une ZEP. Au moins, on en discute avant, on crée un carnet des charges et une vague idée de ce que ça pourrait être et on sais ce que le dev va tenter de faire. Un autre avantage énorme, c'est qu'une branche est créée sur le dépôt, branche qui peut être alimentée par des PR régulières qui sont soumises au même règle que les autres PR (QA, tests, toussa), donc qui peuvent être plus petites et passer plus vites. On a là un outil de dev formidable, autant s'en servir.
• Dans le cas contraire, trouver quelqu'un qui assume de faire de la QA sur une branche à part, quelque part dans un fork. Au moins, on arrive pas un jour avec un gros paquet de code à tester: quelqu'un a déjà fait la QA au fur et à mesure et peut dire : "ok, tu me teste le comportement général, tu teste ça, ça et ça, et logiquement c'est bon". En plus, ce mec là sais bien de quoi il en retourne, donc il est plus efficace dans les éventuelles gestions de conflits et tout ça. Autrement dit, ne bossez jamais seul sur un machin qui devient trop important.
• Je n'arriverai jamais à faire confiance à des tests d'intégrations. D'autant quand on voit maintenant que les tests Travis mettent à peu près 30 minutes pour s'exécuter (un peu moins en local, mais soit). C'est très long, et j'avoue que je ne passe pas ma vie à lancer tout les tests en local à chaque fois (c'est plus long qu'un café!). Si on met en place des tests d'intégrations, il faudra être d'autant plus vigilant en préprod'.

Je sais de quoi je parle, je passe 50% de mon temps de dev pour ZdS à faire de la QA (même si je viens de prendre deux mois de "vacances" pour écrire mon mémoire). C'est pas un reproche, mais il faut pas oublier que je reste un être humain, avec des sensibilités, des préférences et une vie IRL. Je pense qu'Eskimon vous dira pareil: on est pas des machines, et ça sert à rien de râler si les PRs passent pas vites. Et puis sérieusement, ça pourrait être pire, on a pas des vieux machins que personne veut jamais QA (actuelement, les vieilles PR qu'on a, c'est des devs qui manquent de temps pour aboutir, JAMAIS un manque de QA, j'y met un point d'honneur). J'ai donné des pistes plus haut pour améliorer ce point, à prendre ou à laisser

Quand à l'accueil des nouveaux, j'avoue que des personnes responsables seront toujours plus efficaces que n'importe quelle doc/texte/tuto/article/whatever (étonnant pour un codeur de dire que la machine ne remplacera jamais l'être humain, non ?). Ça veut pas dire qu'un tuto ne doit pas être écris ou que la doc pas améliorée, mais elle doit pour moi pointer ces personnes de références. Il ne faut ceci dit pas que ça devienne un truc trop énorme: ces personnes de référence seront en général choisies pour leurs connaissances approfondies sur le sujet et leur contributions nombreuses: ce serait bête de les perdre pour ça. C'est d'ailleurs pour ça que je ne me propose pas (en plus du fait que ma vie ne me permette pas d'être "régulier" dans mes interventions pour le moment).

Un petit mot de la fin: comme je l'ai dit en début d'intervention, le jour ou on ne discutera plus de tout ça, ZdS sera mort. On peut se prendre la tête, râler, bouder, hurler, mais au final, il ressort de tout ça des idées et des point de vue intéressants. Le tout, c'est d'éviter de claquer la porte pour une raison ou d'une autre, parce que c'est domageable au projet et que tout le monde est nécessaire. D'ailleurs, personne n'as de mauvaises idées, pas que je sache. Faut juste prendre le temps d'en discuter.

Sorry pour le pavé.

. Non, sérieusement, des machins énormes comme la ZEP-03, feu la PR sur la désinscription ou des fonctionnalités avancées telles que celle proposées par Firm1 prennent du temps à être QA (et c'est souvent de la QA pas drôle, parce qu'elle est longue), demande dès lors plusieurs rebases (oui c'est pas drôle les rebases), plusieurs allez et retours entre le code, le dev', parfois même plusieurs devs et plusieurs personnes qui font de la QA, mais … C'est comme ça.

d'ailleurs en passant juste comme ça :

maintenant que la ZEP 03 est mergée, une amélioration des outils de dev et de test l'a aussi été. En effet, désormais, il est possible de créer des scénario à charger automatiquement simplement avec des fichiers yaml. Ainsi, pour reprendre l'exemple de la PR de désinscription, il aurait été très simple de faire :

• chargement d'un tuto validé
• chargement d'un tuto en béta
• chargement d'un tuto en écriture
• les trois même mais avec un co auteur
• création de MP
• création de galleries (avec et sans coauteurs)

et tout ça automatisé, ce qui permet un chargement des données en 45 secondes montre en main, pour ensuite faire le test a la mano et donc éviter de passer 25 minutes par test comme le faisait Eskimon à chaque fois.

La commande à utiliser c'est python manage.py load_factory_data chemin_vers_le_fichier_yaml.

Quand à l'accueil des nouveaux, j'avoue que des personnes responsables seront toujours plus efficaces que n'importe quelle doc/texte/tuto/article/whatever

Du coup je reposte ma candidature pour être un "accueil" pour le dev back.

et tout ça automatisé, ce qui permet un chargement des données en 45 secondes montre en main, pour ensuite faire le test a la mano et donc éviter de passer 25 minutes par test comme le faisait Eskimon à chaque fois.

Oh, c'est nice, ça, j'avais pas compris la puissance du machin !! T'as un demi bout de doc à ce sujet, que je vois si y'a moyen de faire des trucs utiles avec ça ? (une instruction typique de QA étant "créez un tuto et validez le", ça serait bien de faire ça en une commande, comme tu dis )

Je vais l'écrire et ajouter deux ou trois factory bien sympa, sachant que la factory "faire un tuto publié" existe déjà. Idem pour les articles.

D'autant quand on voit maintenant que les tests Travis mettent à peu près 30 minutes pour s'exécuter (un peu moins en local, mais soit). C'est très long, et j'avoue que je ne passe pas ma vie à lancer tout les tests en local à chaque fois (c'est plus long qu'un café!)

Et encore il en manque pas mal Je pense aux forums, articles, tutoriels qui ont besoin d'une refonte à ce niveau la. Il faut que je regarde de plus près pour optimiser à la fois sur Travis et en local, je pense qu'il y a moyen de faire mieux que actuellement.

Je n'arriverai jamais à faire confiance à des tests d'intégrations

Est-ce-que tu peux expliquer pourquoi en détail (hormis le temps qu'ils mettent pour s'exécuter) ?

Ça me paraît bizarre de lire ça et d'un autre côté "la QA prend un temps fou". Le coup sur les pouces vert/rouge c'est vraiment le truc qui me semble être un cas d'école, c'est une perte de temps que quelqu'un aille regarder ça. Tu peux le faire en auto et SURTOUT, le jour où quelqu'un casse à nouveau la fonctionnalité par mégarde, ton test t'alertera.

Si c'est HS, on peut en discuter ici

Je vais en dire deux choses:

1. Je ne fait pas plus confiance a des tests unitaires, malgré que j'en écris ;
2. Je n'ai pas dit que c'était inutile pour autant et en aucun cas je ne soutiendrai pas l'implémentation de tels tests

Pourquoi ? Parce que si c'est comme ce qui ce passe aujourd'hui, le test va être écris dans un contexte de bug: "ah, j'ai fixé ça, j'ai pas envie que quelqu'un casse tout, je vais mettre ce test en place". J'insiste encore une fois, mais c'est une bonne chose. Le problème, c'est que ce test est souvent écrit pour prendre uniquement en compte le réglage du bug ou les fonctionnalités principales de la feature. En gros, le mec qui va écrire son test va souvent décrire les notes de QA de la même manière : "avant ça buggait, maintenant, si tu le fait, ça bugge plus". Passons sur le fait que le test ne peut pas être complet, faire de la QA, c'est connaitre un minium le site pour se dire: "oui, mais attend, si il touche à ça, ça va impacter ça, ça et ça, faut que j'aille vérifier". Plus terre à terre aussi, c'est que les tests unitaires se foutent de l'intégration avec le site, des éventuelles fautes d'orthographe ou du fait que le texte déborde de son cadre. Des choses qu'on ne voit pas forcément non plus quand on fait du code review genre "ok c'est correct, mais tu pourrais faire ça comme ça" ou "ça sert à rien, ta ligne, là".

Effectivement, des tests permettraient d'éviter des régressions sur des choses aussi obvious que la couleurs des pouces ou autres, et c'est pourquoi (et j'insiste), je ne suis pas contre, loin de là. Mais je ne me reposerai jamais totalement sur des tests pour faire le travail de QA, qui fait aussi appel au vécu et à la connaissance de ce qui se passe autour.

Voilà

OK, donc au final on est sur la même longueur d'onde, je vois la cruche à moitié pleine, toi à moitié vide

L'idée c'est de soulager la QA, ça ne remplace évidemment pas ni les TU, ni la QA. Ça se place exactement entre les deux. Pour moi la QA devrait effectivement garder un oeil sur les corrections de bug ET justement, donner des indications pour renforcer ces tests. Quand tu dis "oui mais faut vérifier avec des noms tordus" => carrément, et il faut l'écrire quelque part. C'est du savoir-tester, il ne faut pas se reposer sur la QA en tant que personne. Le jour où toi ou Eskimon n'êtes pas/plus là, au plus tu auras de TI "made in QA" au plus les dev auront l'assurance qu'un grand nombre de régression peuvent être repérées.

Le temps passe et le projet grossit donc il me semble urgent de s'atteler concrètement à toutes ces questions. Le premier message de Kje me semble très complet quant aux pists à suivre. Néanmoins, avant de chercher à documenter le projet, il faut se poser la question de qui on souhaite s'occuper.

L'objectif n'est assurément pas d'enseigner les bases techniques aux amateurs pour leur permettre de contribuer. De l'autre côté, on souhaite indéniablement faire intégrer le projet à des personnes pouvant s'impliquer sérieusement. Mais où est la limite ?

Que fait-on de ceux ayant les connaissances techniques mais pas le temps ou l'envie de s'investir sur le long terme ? Cela vaut-il le coup (est-ce possible ?) de tout détailler à l'extrême dans des tutoriels pour qu'ils puissent contribuer en coup de vent sans trop d'efforts, c'est-à-dire contribuer sans connaître le projet dans sa globalité (ou, tout du moins, le back ou le front) ?

En somme, jusqu'à quel point souhaite-t-on que les gens s'impliquent pour être capables de contribuer ?

Je pense avant tout que dès que les gens entendent "contribuer", ils se voient en train de taper des lignes de code (alors qu'il n'y a pas que ça). Ça en rebute énormément, et je ne sais pas quoi faire pour éviter ça.

L'objectif n'est assurément pas d'enseigner les bases techniques aux amateurs pour leur permettre de contribuer. De l'autre côté, on souhaite indéniablement faire intégrer le projet à des personnes pouvant s'impliquer sérieusement. Mais où est la limite ?

Je pense que la personne doit montrer qu'elle a envie de s'investir, le reste viendra de lui-même

Que fait-on de ceux ayant les connaissances techniques mais pas le temps ou l'envie de s'investir sur le long terme ? Cela vaut-il le coup (est-ce possible ?) de tout détailler à l'extrême dans des tutoriels pour qu'ils puissent contribuer en coup de vent sans trop d'efforts, c'est-à-dire contribuer sans connaître le projet dans sa globalité (ou, tout du moins, le back ou le front) ?

C'est énormément demandeur en temps de tout documenter, ce pourquoi il faut y aller petit à petit. La méthode d'éditer la doc au fur et à mesure des PR n'était (n'est ?) pas mauvaise, on a réussi à réaliser une petite doc qui vaut ce qui vaut. Récement, certaines personnes se sont également lancées dans l'ajout systématique de docstring.

De toute façon, on peut pas demander à quelqu'un "d'étudier" le projet avant de contribuer, c'est pas possible. Je découvre personnellement le projet en même temps que j'y contribue ("ah, tient, ça c'est là, c'est codé comme ça"). Une contribution en "coup de vent" peut également être bénéfique au projet et ne doit pas être refusée (parce que peut-être que la personne va vouloir recommencer par après).

Drôle de question, selon moi.

Je pense avant tout que dès que les gens entendent "contribuer", ils se voient en train de taper des lignes de code (alors qu'il n'y a pas que ça). Ça en rebute énormément, et je ne sais pas quoi faire pour éviter ça.

Le problème, d'ailleurs soulevé dans ce sujet, c'est qu'on ignore quoi faire d'autre.

Drôle de question, selon moi.

Pourquoi ?

Dans mon cas par exemple, je souhaite contribuer au projet, je possède un certain nombre de compétences en dev mais n'ai absolument pas le temps de m'y pencher sérieusement. Et ça donne ça.

Désolé pour le temps de réaction, mais en lisant ça :

Je ne peux pas m’empêcher d'avoir l'impression de prêcher dans le désert. Mais comme dirait l'autre, ce n'est qu'au pied du mur, qu'on voit le mur. Pour moi qui suit un maniaque de la prévision, je trouve ça vraiment dommage. Quand je dois qualifier un outil pour un projet aussi sensible que ZdS, je prend la peine de l'essayer sur la majeure partie des systèmes d'exploitations (car on ne sait pas toujours quel sera le système d'exploitation du contributeur potentiel) et pendant un certain nombre de temps. C'est principalement la raison pour laquelle je ne voyais pas d'un très bon œil l'utilisation de Docker (problème sous Windows) ou le passage a libgit2 (nécessité de Visual studio à l'époque). Je ne suis jamais fan d'imposer un OS, un soft, une version de navigateur, etc qui ne soit pas ultra nécessaire, pour moi c'est ça rester ouvert au maximum.

Le soulagement de la QA par les tests

Pour rester dans le sujet, et sur un sujet qui fait moins polémique, on dirait que l'idée de tests d’intégration poussée est partagée. On appelle ça plus communément le Behavior Driven Developpement. Le principe est, pour chaque fonctionnalité du site d'écrire un scenario de test qui sera exécuté. L'avantage ici est que les scénaris peuvent être écrit par n'importe quel membre du site et seront exécutés comme si l'utilisateur lui même ouvrait son navigateur et réalisait les actions. Ainsi une ZEP aurait pour livrable un ensemble de scenaris. Pour exemple un ensemble de scénaris peut prendre cette forme (une fonctionnalité s'écrit en Gherkin).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

Fonctionnalité: Inscription
    Pour parvenir à utiliser le site pleinement en tant qu'utilisateur nous devons être inscrit

    Scénario: Accéder à la page d'inscription étant déconnecté
        Je ne suis pas connecté
        Quand je vais sur le lien inversé "register"
        Je vois dans le titre1 "Inscription classique"
        Je vois dans le titre1 "Inscription via reseau sociaux"

    Scénario: Réaliser une ou plusieurs inscription(s)
        Utiliser selenium
        Je ne suis pas connecte
        Je vais sur le lien inversé "register"
        Je remplis le champ "id_email" avec "<email>"
        Je remplis le champ "id_password" avec "<password1>"
        Je remplis le champ "id_password_confirm" avec "<password2>"
        Je remplis le champ "id_username" avec "<username>"
        Clique sur le bouton "input[name=submit]"
        Le résultat de la soumission du formulaire doit etre "<result>"
        Si "<result>" est OK alors j'ai reçu un mail dont l'objet est "Confirmation Inscription"
        Si "<result>" est OK alors j'ai reçu un mail avec dans le message "Merci"
        Si "<result>" est OK alors je ne peux pas encore me connecter avec "<username>" et "<password1>"
        Si "<result>" est OK alors je clique sur le lien d'activation dans le mail
        Si "<result>" est OK alors je peux me connecter avec "<username>" et "<password1>"

    Exemples:
        | email             | password1   | password2   | username | result |
        | user1@gmail.com   | password1   | password1   | user1   | OK      |
        | user2@gmail.com   | password1   | password2   | user2   | KO      |
        | user3@gmail.com   | user3       |  user3      | user3   | KO      |
        | user1@gmail.com   | password1   | password1   | user4   | KO      |

Les outils du marché dans le monde python

Pour faire ça, il existent trois principaux outils dans le monde python qui savent le faire.

• Lettuce
• Freshen
• Behave

Il font plus ou moins sensiblement le même travail dans le fond. Cependant, après plusieurs semaines de tests sur le code de ZdS, le choix étais toujours aussi difficile à faire. Entre Behave et lettuce.

L'un des gros point fort de lettuce par rapport au reste est sa meilleure intégration avec Django ainsi que la possibilité de faire du code coverage (donc il est possible de le brancher à coveralls pour completer notre couverture de tests actuels). Son plus gros point faible étant qu'il est pas compatible python 3

L'un des gros point fort de behave par rapport à lettuce est qu'il est compatible python 3, mais l’intégration à Django n'est pas aussi bonne qu'avec lettuce. Ce qui est normal puisque lettuce a 1 an d'ancienneté devant behave.

Mes tests sur ces deux outils remontent quand même (2-3 mois je dirais) mais il sont toujours d'actualité. Si ça intéresse du monde, il est possible de faire un POC de BDD sur une ZEP.

La stack pourrait être :

• lettuce/behave
• selenium (n'ayez pas peur, c'est juste un fichier jar de 3 Mo à télécharger et à lancer)

Tout ceci à inclure dans travis (ce qui pourrait considérablement augmenter le temps d’exécution des tests). Car une feature comme celle présentée ci-dessus consomme environ 15 secondes (normal puisqu'on lance un navigateur et on attend les retours de page). Avec environ 100 features l'équivalent de l'existant on pourrait aller jusqu’à 30 mins en plus.

Voilà, vers quoi on peut s'orienter pour les tests fonctionnels/de comportement.

Va falloir ajouter le browser embarqué du navigateur de votre choix à la stack que tu mentionnes je pense (Chrome, FF, …). Selenium pilote le driver, mais il lui faut évidemment un driver.

Par contre, je pense vraiment que le plus souple et le plus itératif c'est de démarrer ce genre de tests sur des corrections de bug.

Il va falloir un certain temps pour se familiariser avec l'outil et du coup, mieux vaut faire simple qu'exhaustif, de plus la spec' de test serait très restreinte (en gros : décrire le bug rencontré, vérifier qu'il ne se produit plus), là où la spec de test complète d'une ZEP va être horriblement longue.

Si j'ai un conseil à donner ce serait vraiment celui-là, on est en train d'essayer des outils, les comparer, voir si c'est rentable et efficace (cf. ta remarque sur le temps d'exécution) : mieux vaut l'appliquer sur des cas simples, qui au pire serviront par la suite de non-régression, plutôt que se lancer dans une méga-feature.

Pour npm de ce que j'en ai compris le problème n'est pas l'outil, mais la façon dont il est utilisé. Builder des fichiers front avec npm tout le monde le fait, balancer le résultat du build directement sur la prod par contre je pense que pas grand monde s'y risque. With all due respect je pense que tu fais un mauvais procès : c'est pas npm en lui-même qui est en cause, mais la communication autour des outils. Et là, on est tous responsables. Et sans vouloir être méchant j'ai plus l'impression que tu fais l'autruche en disant "haha je l'avais dit, npm c'est dla merde". Toutes les discussions (sur le site en tout cas) à propos de npm portait sur l'environnement de développement, là le problème est bien plus emmerdant, parce qu'il touche à l'intégration continue et au processus de mise en prod. Sans dire que les deux ne sont pas liés, ta remarque me semble hors-sujet.

Va falloir ajouter le browser embarqué du navigateur de votre choix à la stack que tu mentionnes je pense (Chrome, FF, …). Selenium pilote le driver, mais il lui faut évidemment un driver.

Yop, je l'avais oublié ceclui là.

Par contre, je pense vraiment que le plus souple et le plus itératif c'est de démarrer ce genre de tests sur des corrections de bug.

Exact. Un bug n'est au final qu'un comportement qui n'a pas été testé. Et du coup si on spécifie tous les comportement possible pour une inscription par exemple il y'a de très grandes chances qu'on sorte tous les bugs lié à l'inscription.

Quand je parlais de tester sur une ZEP, c'était surtout pour voir jusqu'a quel point ça peut rester scalable.

Pour npm de ce que j'en ai compris le problème n'est pas l'outil, mais la façon dont il est utilisé. […]

C'est bien ce que j'ai décris en disant que en production, la façon dont on l'utilise nous empêche de réaliser un déploiement natif django.

Le lien avec la stack de dev a peu près le même que celui qui se présente en prod aujourd'hui : la stabilité de npm sous debian. Ce qui est mit en lumière ici est le fait que si on veut contribuer depuis un OS qui n'est pas dernier cris, on doit essuyer pas mal de plâtres.

Je voulais juste intervenir sur ce sujet ;

Il faut revoir ta définition de l'open-source. Ce n'est pas "Il faut rendre le projet compatible avec TOUT". Avec ce genre de raisonnement, à coté, le monde merveilleux des bisounours et des licornes n'est plus une utopie…

Développer un truc open-source, c'est certes "ne pas fait faire de trucs trop spécifiques", mais faut penser à un truc… si on développe ZdS, c'est aussi.... pour faire tourner ZdS ! Notre code est ouvert ; si quelqu'un veut utiliser ZdS dans son coin, qu'il le fasse. Ça s'appelle plus de la "mise à disposition" en fait…

Et à propos de la stack NPM, et ça fait plusieurs fois que je vois ça ; je ne suis pas dev front, mais c'est quand même un des standards du dév front justement. Je dis ça…

P.S : pour le déploiment : capistrano, anyone ?