Tests fonctionnels du site

Hello !

J'ai remarqué sur le site n'était pas vraiment testé de manière automatique. Je me demandais si ça vous intéressait que je PR des tests fonctionnels (j'utilise Behat).

Le principal problème c'est que ça rajouterait du PHP sur le projet, donc si vous y êtes alergique, c'est un peu bof. Sinon qu'en pensez vous ?

J'ai remarqué sur le site n'était pas vraiment testé de manière automatique. Je me demandais si ça vous intéressait que je PR des tests fonctionnels (j'utilise Behat).

Il y a déjà des tests unitaires pour tout le back. Pour le front c'est en discussion. Toute aide est bonne a prendre mais je ne suis pas surs que le PHP soit le plus adapté, ça nous rajoute une dépendance chez tous les contributeurs qui me semble un peu exagéré.

PS: je déplace en zone dev car la section "Site Web" des savoirs n'est pas adaptés aux question concernant le site.

Mais la l'OP parle de test fonctionnel, donc si je me trompe pas et vu la page de présentation du logiciel, ca parle de "Use Case" que tu décris et non pas de test technique (donc test manuel VS test auto).

Oui j'ai pas dis le contraire même si c'etait pas tres clair.

Je pense qu'il parle de tests fonctionnels automatisés.

Beaucoup de frameworks font cela, je connais Selenium et Geb pour les avoir utilisés.

En gros tu décris une fonctionnalité :

l'utilisateur charge la page, saisit son message dans le textarea #bidule-chouette, il clique sur le bouton #valider-machin, il doit se retrouver sur une nouvelle page dont l'URL est /bidule/machin, avec son message dans le div #message

Si vous choisissez une techno sympatoche pour écrire les tests fonctionnels (tests d'intégration en fait) ça peut être un projet hyper cool pour des débutants que d'écrire des petits bouts de tests

EDIT : en fait pas sûr qu'on parle vraiment tous de la même chose, perso je fais la distinction entre :

• tests automatisés du code serveur (déjà en place)

• tests automatisés du code client (tests de certaines logiques JS par exemple : c'est le cas déjà ?)

• tests d'intégration (qui donc vont tester les deux) avec un driver web

EDIT² : avec Geb par exemple :

 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

import geb.Browser

Browser.drive {
    go "http://google.com/ncr"

    // make sure we actually got to the page
    assert title == "Google"

    // enter wikipedia into the search field
    $("input", name: "q").value("wikipedia")

    // wait for the change to results page to happen
    // (google updates the page dynamically without a new request)
    waitFor { title.endsWith("Google Search") }

    // is the first link to wikipedia?
    def firstLink = $("li.g", 0).find("a.l")
    assert firstLink.text() == "Wikipedia"

    // click the link 
    firstLink.click()

    // wait for Google's javascript to redirect to Wikipedia
    waitFor { title == "Wikipedia" }
}

M'étonnerait que y'ait pas le même genre de libs en Python

Oui je parle de tests fonctionnels et pas unitaires, en effet.

Et behat peut fonctionner avec Selenium ou PhantomJS. Je vous invite à lire la première page du site de behat pour voir comment cela se présente.

La dépendance "PHP" est uniquement pour les devs qui souhaitent exécuter les tests (travis fait le job pour ceux qui ne veulent pas s'en encombrer).

On fait tout en Python côté serveur jusque là. Ça me semble un peu abusé de rajouter une techno pour des tests fonctionnels.

À la limite, c'est faisable avec node.js puisqu'on l'utilise pour le front. Mais le mieux ça serait de faire ça en Python car les dev back n'ont pas node.js globalement.

Okok, vous êtes alergique au PHP . Que diriez vous de le faire en Ruby ?

Okok, vous êtes alergique au PHP

Ce n'est pas le fait d'être allergique au PHP, ou non, mais comme dit, actuellement tout côté serveur est réalisé en Python, il n'y a aucune ligne de PHP, donc pourquoi allez en rajouter à ce stade du projet ?

@Flori@n.B comme dit, c'est une dépendance uniquement dev/test. Au delà de cela, tout n'est pas réalisé en python puisque nodejs est utilisé.

Après moi je ne fais que proposer de l'amélioration de maintenance. On a le droit de me dire non .

Après moi je ne fais que proposer de l'amélioration de maintenance. On a le droit de me dire non .

Et cette dernière est bienvenu D'un point de vue purement pratique, je pense que tout le monde s'accorde à dire que plus il y a de tests (sans qu'il soit redondant bien sur) et mieux c'est

Après comme dit plus haut, si on peut éviter d'avoir une autre techno/serveur à maintenir ce serait quand même un plus (sans compter qu'il faut aussi avoir les personnes sur le long terme our connaitre cette techno).

Coucou,

Alors je passe donner mon avis. Je suis plutôt pour une politique ou on a le maximum de tests. Aujourd'hui on a de plus en plus de tests unitaires du coté du back-end (75% de couverture sur un site web c'est quand même énorme). Les tests inclus même des tests d'intégration dans le sens ou on teste des workflow complets.

Je pense que ce qui manque le plus au site aujourd'hui ce sont des tests front, il y'a quasi aucun test coté frontend.

En ce qui concerne les tests fonctionnels du style behat, j'ai souvent le sentiment que la différence entre eux et les tests d'intégration c'est que ces tests fonctionnels sont plus lisibles pour le lambda user. Si ça peut améliorer la qualité, pourquoi pas, mais il ne faudrait surtout pas rajouter une nouvelle technologie en plus. L'équivalent de cucumber (que je connais plutôt bien) en python c'est Lettuce. Donc si vous voulez proposer des tests fonctionnels, le mieux serait de s'orienter ver Lettuce. L'avantage étant :

• on garde une d'oc d'install du projet (et outils de test) simple a lire
• on reste sur un seul langage obligatoire (python) et un langage optionnel coté front (nodejs).
• celui qui s'y est mit au python pour le site, n'a pas besoin de s'y mettre au php/ruby pour les tests et donc il pourra écrire aussi des tests fonctionnels.

Voilà en gros ce que j'en pense

Je pense que ce qui manque le plus au site aujourd'hui ce sont des tests front, il y'a quasi aucun test coté frontend.

Les seuls tests en place sont ceux sur la normalisation du code JS.

Au delà de ça, c'est beaucoup trop compliqué à tester vu les dizaines de configurations qu'on couvre, je ne pige même pas l'avantage qu'on aurait à avoir des tests front. En fait, je n'en n'ai jamais fait. Je ne comprends pas ce qu'il y aurait à tester. La structure HTML ? En général ce qui plante c'est le CSS. Le HTML est méga-factorisé, donc il y a très peu de chance de casser le site d'un côté en touchant à un autre.

Encore une fois, j'y vois confusion entre tests du code côté client et tests d'intégration.

C'est pas du tout le même esprit.

Les tests côté client, à mon sens, c'est écrire des tests unitaires du code JS utilisé en front. Par exemple : tu écris une surcouche à $.ajax, tu t'assures qu'elle se comporte comme tu le souhaites en fonction des codes http retournés (réessaie périodiquement sur une 503, abandonne sur une 500, …). On parlait d'AngularJS dans un autre topic, il en va de même pour lui : s'assurer qu'une directive fait le job pour lequel on l'a codée, c'est essentiel.

CA c'est ce que j'appelle tets-front. Plus ton application adopte le modèle "single-page-webapp" au mieux ça s'adapte.

Les tests d'intégration c'est pas la même chose selon moi. Peu importe qu'on teste le front ou le back, on teste une fonctionnalité telle qu'elle est vue (et doit être utilisée) par un client. Typiquement pour ZdS : le +1/-1 sur un message du forum. Y'a plusieurs moyens de couvrir des tests là-dessus :

1. on teste programmatiquement le back en tests unitaires :

1
2
3
4
5
6

User user = new User(); 
Message[] messages = topic.messages; 
for(message in messages)
{
  MessageServiceProvider.upVoteMessage(user, message);
}

1. On teste une API :

1
2
3
4
5
6

Client http = new HttpClient();
Message[] messages = http.get("/forums/lala/messages");
for (message in messages)
{
  http.put("forums/messages/{message.id}", {vote:+1});
}

1. On teste la fonctionnalité sur le site

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

Browser.drive {
    go "http://zestedesavoir.com/forums/sujet/721/tests-fonctionnels-du-site/?page=1#p9915"

    assert title == "Tests fonctionnels du site"

    $(".upvote").each { upvoteButton ->
        upvoteButton.click();
    }

    waitFor { /* condition pour que ce soit fini */ }

    $(".upvote").each { upvoteButton ->
        assert upvoteButton.hasClass("has-vote")
        // ...
    }
}

Et dans ce cas, on s'en fout complètement du front ou du back, on teste la fonctionnalité du point de vue utilisateur final. Il se peut que le test ait échoué parce que le bouton n'est pas dans la page (template HTML cassé) ou que la BDD peine un peu (503 retournée par le serveur ?), que les votes ne soient pas compatibilisés correctement (bug dans la logique serveur). A nous de bétonner les tests pour qu'en cas d'échec on trouve le responsable.

En gros, si les tests unitaires allègent (pas dans le sens donne moins de travail, mais dans le sens "le coeur léger") le boulot du dev, les tests fonctionnels allègent la QA. En QA tu auras l'assurance que si tu trouves un bug c'est un truc assez vicieux, et qu'il faut écrire un test pour que ça soit détecté dans le futur. D'ailleurs, si quelqu'un est bien placé pour écrire ces tests, ce sont les gens qui font la QA, pas les développeurs front. Il s'agit d'automatiser un maximum leur travail pour qu'ils ne fassent pas 80 allers-retours avec les devs à chaque recette.

Au vu de lettuce, +1 pour ça. En fait, je suis juste vachement pour les tests d'acceptation (Behat, Cucumber, Lettuce donc). Et puisque l'équivalent python (lettuce) existe, autant rester sur du python…

CA c'est ce que j'appelle tets-front. Plus ton application adopte le modèle "single-page-webapp" au mieux ça s'adapte.

Justement, on est pas du tout single-page-webapp, du coup je ne comprends pas ce que veut dire firm1… des tests en front, actuellement, ça ne servirait à rien : il n'y a rien à tester (ou alors, le check fait par JSHint est suffisant).

Mais pour les tests fonctionnels : là j'suis d'accord

TOUT est testable. TOUT doit être testable. Même si y'a plusieurs configs. Regarde du coté de Mocha ou KarmaJS (c'est ce qu'on utilise au boulot).

@Alex : C'est très exactement pour cela que je parlais de confusion.

J'ai jeté un oeil au code JS et je suis assez d'accord pour dire qu'en l'état sortir l'artillerie Karma/Jasmine/PhantomJS n'a pas beaucoup d'intérêt. Si je dois mettre une pièce, je dirais que ça en aura dès que le front disposera d'un outil très poussé (et l'éditeur me semble être un bon candidat). Ce jour là y'a plutôt bien intérêt à s'armer.

@Talus : oui je suis d'accord. Mais il faut aussi prioriser et je pense qu'aujourd'hui la valeur ajoutée sur le code JS reste faible. Mais ça changera certainement.

@ToutLeMonde : J'ai regardé la doc de Cuncumber (Lettuce donc, par extension), ça me paraît être un très bon outil pour la QA. D'ailleurs commencer par décrire dans ce format les QA existants serait une bonne idée pour se mettre le pied à l'étrier non ?

C'est un peu tombé dans l'oubli cette histoire, à vrai dire j'y ai repensé en tombant par hasard là-dessus.

Je pense que c'est vraiment un bon petit projet pour des gens qui veulent se mettre tranquillement à Python (écrire des tests c'est souvent beaucoup plus une question d'API que de langage, mais ça permet de se mettre le pied à l'étrier) et de contribuer différemment au site.

Pour avancer sur le sujet :

• Créer un projet de test dans le repo. Eventuellement avec un test basique qui sert de doc : afficher la page d'accueil et vérifier que Clem est toujours là pourrait être un bon exemple

• Se mettre d'accord sur l'organisation des specs de test pour que ce ne soit pas le foutoir : où on les met, comment on les organise (une spec par page, une spec par feature, …)

• Ajouter une doc sur comment installer le framework de test et le faire tourner sur sa version locale de ZdS

• Ajouter des scripts pour faire tourner les tests d'intégration sur la preprod.

• Songer à l'intégration continue ? S'assurer que les dev' (front/back) les lance avant de commiter ?

Vous voyez d'autres trucs ?

Suite de cette discussion

J'imagine que tu as bossé avec le driver Selenium directement SpaceFox non ?

Si c'est le cas, je pense que tu as pu constater à quel point les primitives de l'API Selenium sont mal foutus, bas niveau et franchement a pain in the ass à utiliser. C'est vieux, c'est chiant. Faut dire ce qui est.

Je comprends bien l'argument de "pas besoin de DSL, je sais ce que je fais". OK. J'entends.

Simplement, le truc qu'ils occultent complètement, ce n'est pas forcément qui écrit les tests, mais qui va les lire.

Peut-être qu'un retour d'expérience est plus parlant (ou pas, m'enfin au moins ça peut servir). On s'est posé cette question au bureau il y a quelques temps, et après moult discussions (qui en essence ressemblaient à cet article hein), on a fait le choix de remplacer les tests Selenium classiques par geb.

Un peu plus d'un an plus tard, où en est-on ?

Les dévs front écrivent des tests aujourd'hui. Et mine de rien, c'était pas gagné, du tout. La syntaxe "jquery-like" (donc DSL hein, on est en plein dedans) leur simplifie énormément la vie et j'irais même jusqu'à dire leur plaît. Ils comprennent ce qu'ils lisent et ce qu'ils font. Avec Selenium "brut" tu peux être certain qu'ils auraient été rebutés.

Quand un test échoue, les gens qui ne sont pas techniques arrivent à lire les stacktraces (et c'est ce qui m'a le plus surpris) "Element machin is missing". Ca n'a pas d'application concrète, puisqu'ils ne corrigent pas les régressions. Mais vu qu'ils font parfois des tests manuels ils sont plus attentifs aux pages qui ont pété un peu avant.

On gagne énormément de temps à lire les tests. Vraiment. A les écrire aussi, mais c'est moins flagrant. Quand je lis le test de quelqu'un je comprends ce qu'il veut faire, c'est vraiment conçu dans cette optique. Et ça, y'a qu'une DSL qui peut te l'apporter. Je te garantie que c'est extrêmement agréable de lire un truc du style expect $page toBe $home after $login ou ce genre de choses. Tu ne gagnes pas énormément de temps à l'écrire, faut s'approprier une DSL inconnue, ça prend parfois du temps, mais c'est largement rentabilisé par le temps que tu gagnes à relire les tests par la suite.

Alors mon avis peut être biaisé, tout autant que le leur j'ai envie de dire. Mais là, on essaie de s'adresser à des contributeurs qui potentiellement ne connaissent pas Django, ne connaissent pas non plus le code du site mais connaissent ses fonctionnalités.

Là c'est pertinent.

Je maintiens que le message de l'article que j'ai passé n'a pas été compris. Le problème, c'est pas la DSL. Le problème, c'est les DSL lourdingues qui essaient d'imiter le langage naturel.

J'ai bossé 6 mois à plein temps avec ce genre de conneries¹, ça n'apporte qu'une seule chose : rendre le bordel illisible. Les pseudo-phrases, c'est joli dans les exemples, c'est imbitable dans la vraie vie, c'est plein de bruit qui n'aident en rien à la compréhension et ça n'aide personne, parce que quoi que prétendent les concepteurs de ce genre de chose, c'est extrêmement rare que des personnes non techniques écrivent ou relisent ce genre de tests.

Dans ton exemple, tu parles de "dev front". Ce sont des devs. Ils sont parfaitement capables de manier un langage de programmation. La preuve : en choisissant un DSL qui ressemble à un langage framework qu'ils connaissent (jQuery), ils s'en sortent très bien.