Discussion :

[Esil2008]

Salut

Comme il y a peu de documentation sur ce sujet, je reviens vers vous pour avoir vos feedbacks sur des frameworks de tests pour tester des applications JSF, Icefaces, Richefaces ...

Perso, j'utilise pour tester mon appli Icefaces, HtmlUnit c'est pas mal, mais je suis très limité quand c'est question de tester un composant un peu complexe. La par exemple je cale sur le test de deux data table imbriquées. C'est vraiment pas fait pour ca je pense.
Il y a JSFUnit qui apparemment permet de tester les composants JSF, mais avec une petite recherche sur google concernant mon cas. j'ai remarqué qu'il engendre des des conflits entre icefaces et jsf. Des erreurs liées au javascript aussi.

Pourriez me donner vos retours d'expériences concernant ce sujet ?

Et si quelqu'un à deja utilisé Htmlunit pour faire des tests poussés sur des composants icefaces, richefaces ou autre. ca serait bien s'il me montre comment il a procédé

Merci

[tchize_]

pour tester les bean jsf, j'utilise des outils de type comme shale-test, qui fournissent des implémentation Mock des composants JSF et qui me permettent de tester les bean, les EL etc (tout ce qui n'est pas HTML) sans avoir besoin d'un conteneur web (rapide et léger à lancer tout ça). Pour le reste (tester les comportement visuels), j'utilise Selenium, qui permet de lancer directement les teste à travers un browser web (firefox ou IE) après avoir déployé un webapp de test sur un serveur de test.

En pratique, pour cette phase, on a un projet maven2 'test' de type WAR, et dans l'intégration-test on a un combinaison de Selenium server, cargo (pour démarrer un tomcat de test) et des unit tests qui ressemblent à çà:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
 
 
import junit.framework.TestCase;
 
import com.thoughtworks.selenium.DefaultSelenium;
import com.thoughtworks.selenium.SeleneseTestCase;
import java.util.regex.Pattern;
 
public class TextAndDocsParameterTest extends SeleneseTestCase {
        protected DefaultSelenium createSeleniumClient(String url) throws Exception {
                return new DefaultSelenium("localhost", 4444, "*firefox", url);
        }
        public void setUp() throws Exception {
                selenium=createSeleniumClient("http://localhost:6969/");
                selenium.start();
        }
        public void tearDown() throws Exception {
                selenium.stop();
        }
        protected boolean isCaptureScreetShotOnFailure() {return true;}
 
    public void testTextAndDocument() throws Exception {
                selenium.open("test-site/test/HtmlTextAndDocsParameterRenderer.faces");
                assertTrue(selenium.isElementPresent("parameterTestForm:edit:comment"));
                assertTrue(selenium.isTextPresent("Obvious textgoogle (be)google (com)google (uk)"));
                assertTrue(selenium.isElementPresent("parameterTestForm:edit:add"));
                assertTrue(selenium.isElementPresent("parameterTestForm:edit:0:delete"));
                assertTrue(selenium.isElementPresent("parameterTestForm:edit:1:delete"));
                verifyTrue(selenium.isElementPresent("parameterTestForm:edit:2:delete"));
                assertEquals("google (be)", selenium.getText("link=google (be)"));
                assertTrue(selenium.isElementPresent("link=Modifier ce document"));
                assertTrue(selenium.isElementPresent("link=google (com)"));
                assertTrue(selenium.isElementPresent("//a[@onclick=\"if (showBlock('parameterTestForm:edit:1:edit')) removeElementContent('parameterTestForm:edit:1:show'); return false;\"]"));
                assertTrue(selenium.isElementPresent("link=google (uk)"));
                assertTrue(selenium.isElementPresent("//a[@onclick=\"if (showBlock('parameterTestForm:edit:2:edit')) removeElementContent('parameterTestForm:edit:2:show'); return false;\"]"));
                selenium.type("parameterTestForm:edit:comment", "text and document test");
                selenium.click("parameterTestForm:edit:add");
                assertTrue(selenium.isElementPresent("parameterTestForm:edit:3:name"));
                assertTrue(selenium.isElementPresent("parameterTestForm:edit:3:uploadedDocument"));
                assertTrue(selenium.isElementPresent("parameterTestForm:edit:3:uploadedDocument"));
                assertTrue(selenium.isElementPresent("parameterTestForm:edit:3:update"));
                assertTrue(selenium.isTextPresent("Nom"));
                assertTrue(selenium.isTextPresent("Envoyer un fichier"));
                assertTrue(selenium.isTextPresent("Type de document"));
              assertTrue(selenium.isElementPresent("document.parameterTestForm.elements['parameterTestForm:edit:3:DocumentType'][1]"));
                assertTrue(selenium.isElementPresent("parameterTestForm:edit:3:DocumentType"));
                assertTrue(selenium.isElementPresent("document.parameterTestForm.elements['parameterTestForm:edit:3:DocumentType'][2]"));
 
        }
}

Seules limitations rencontrées avec selenium:

1. Pas possible de tester les fileupload (selenium travaillant en javascript)
2. on ne peux rien faire sur la machine pendant ce temps (envahie de fenetre firefox pendant quelques minutes)
3. Les adminitrateur système veulent t'effacer ce virus qui affiche des popups :p
4. Compiler le war + démarrer tomcat, même si c'est automatique dans le test, ca prend du temps (quelques minutes)
5. si tu teste trop fort ton composant, tu dois changer régulièrement tes tests (en particulier si les ids changent souvent, selenium se basant fortement là dessus)

j'avais testé à une époque des framework du type HttpUnit, mais c'est vraiment mal adapté (pas de test de javascript, analyse du html brut nécessaire, le moindre changement dans le html fait sauter le test, pas de garantie visuelle).

Cerise sur le gateau, les unit test selenium peuvent faire un capture d'écran lors du failure du test (non seulement tu sais quoi foire, mais tu sais ce qu'il y avait à l'écran à ce moment là :p)

[Esil2008]

Merci beaucoup pour ta reponse,

J'avais vu un peu selenuim mais vite fait, j'avais preferer utiliser HtmlUnit croyant que c'est plus pratique par ce qu'il est a priori plus utiliser...


En tous cas je vais me lancer dans tests plus pousser avec Selenium, j'espere qu'il pourra me tester mes data table


Merci encore

[romaintaz]

Il existe aussi JSF Unit de JBoss, mais je ne l'ai jamais essayé. Quelqu'un a un retour à faire sur l'outil ?

[Esil2008]

Salut tchize_,

Est ce que tu aurais un peu de doc sur Shale ? a part la doc du site officiel. Car sur leur site je ne vois pas par ou commencer, de mon humble avis je trouve que c'est mal organisé pour quelqu'un qui ne sait absolument rien du tout sur Shale ou les implementations Mock

[tchize_]

non j'ai pas de doc. J'ai juste utilise la javadoc pour voir quelles classes existaient et les manipuler. Le reste, comme c'est juste des bêtes classes, ca a pas été trop dur (pas de config particulière à faire, etc)


http://shale.apache.org/shale-test/apidocs/index.html

[Esil2008]

Merci pour ta réactivité,

tu n'aurai pas quelque part sur ta machine un exemple d'une classe hello world avec ce framework qui traine encore, ca m'aidera a commencer ?

EDIT : Desole je crois que j'ai écrit vite, je pense qu'il propose des exemples si je telecharge ce framework !

Merci

[tchize_]

le framework de test est de toutes facon utilisé par shale en lui même pour ses unit test -> suffit de regarder les unit test

[*alexandre*]

Es-ce possible d'initlialiser des test avec des champs autocomplete sur une application qui utilise des tabbed pane d icefaces ??? si c'est possible je me demande bien comment ...

[tchize_]

avec selenium, tu peux tester tout ce que tu veux coté browser. (sauf les file upload). Principe, un serveur java pilote le navigateur (firefow ou ie ou autre) par javascript pour simuler le comportement de l'utilisateur. Les requetes sont elles, effectuées par un vrai serveur (tomcat, jboss ou autre) qui donne les réponse. Plus qu'à tester que les pages correspondent à ce qu'on attends.

[*alexandre*]

avec selenium, tu peux tester tout ce que tu veux coté browser. (sauf les file upload). Principe, un serveur java pilote le navigateur (firefow ou ie ou autre) par javascript pour simuler le comportement de l'utilisateur. Les requetes sont elles, effectuées par un vrai serveur (tomcat, jboss ou autre) qui donne les réponse. Plus qu'à tester que les pages correspondent à ce qu'on attends.

Merci ça l'air intéressant en effet

[Esil2008]

Salut tchize_,

Pourrais tu m'éclaircir sur certains points que je comprends pas encore et me corriger au cas ou je me trompe ?

- Concernant Shale Test, si j'ai correctement compris, je dois créer des mocks qui représentent mes composants JSF pour pouvoir les tester par la suite.

- Shale test me permettra de tester les valeurs du composants, validateurs, converstisseurs ... mais pas le un click ou une action sur ce composants, cela je pourrais le faire avec selinium.

- Le composant à tester doit être créer et initialiser dans la méthode setUp(). Je peux utiliser un composant normal ou bien dois je disposer d'un composant mock ?

- Je ne voit pas comment cette classe de test interagira avec mon backing ou managed bean. Puisque pour tester on execute à ce niveau que des méthode JUNIT, pour moi je vois aucune interaction avec la vue, je pense que je mélange le test de composants avec le test fonctionnel !!!


Merci bq

[tchize_]

- Concernant Shale Test, si j'ai correctement compris, je dois créer des mocks qui représentent mes composants JSF pour pouvoir les tester par la suite.

Non, tu dois les instancier seulement, le but de shale test est justement de te fournir les mock pour les classes de base JSF (FacesContext, ResponseWriter, etc, le tout sans les besoins d'un conteneur J2EE derrière). T'as juste à les instancier et le relier entre eux. Ensuite tu teste tes Beans principalement, mais aussi tu peux tester des converter, etc

- Shale test me permettra de tester les valeurs du composants, validateurs, converstisseurs ... mais pas le un click ou une action sur ce composants, cela je pourrais le faire avec selinium.

En gros c'est çà, pas de test de rendu, c'est léger, pas de browser, pas de serveur, mais évidement ca a ses limites

- Le composant à tester doit être créer et initialiser dans la méthode setUp(). Je peux utiliser un composant normal ou bien dois je disposer d'un composant mock ?

L'idée c'est, soit tu instancie toi même un ou pluieurs Bean et tu les enregistre dans le facescontext, ensuite t'appele la méthode a tester qui utilsie ces bean. Donc ca sert à tester des bout de code qui reposent sur la présence d'un FacesContext, d'un ApplicationContext ou autre factory de JSF. Pour un composant JSF à part entière, il vaut mieux opter pour un test dans un browser, comme selenium. Note que tu peux très bien, je pense, par exemple tester le decode() de ton composant dans un shale-test. T'as juste à lui passer uen fausse requete et lui dire de faire son décode ^^

- Je ne voit pas comment cette classe de test interagira avec mon backing ou managed bean. Puisque pour tester on execute à ce niveau que des méthode JUNIT, pour moi je vois aucune interaction avec la vue, je pense que je mélange le test de composants avec le test fonctionnel !!!

La vue en temps que JSF View sera présente avec toutes ses méthodes via le MockView de Shale test, mais de fait il n'y aura pas "rendu" effectif vers un browser. Et ce sera a toi d'appeler les méthode du composant, car il n'y aura pas non plus construction de l'arbre JSF depuis un JSP ou xhtml facelets.

[Esil2008]

Merci bq pour toute ces précisions, je comprend un peu mieux mnt ce framework

[*alexandre*]

j ai testé Selenium et comme je le pensais ca ne répond pas à mes besoins après deux clicks le recorder n'arrive pas à reproduire mes actions

[tchize_]

le principe c'est d'abord d'enregistrer tes action, ensuite passer sur l'enregistrement et le nettoyer en ne faisant que ce que tu veux faire, en rajoutant des wait là où il faut etc. Et faut pas perdre de vue qu'il faut un envirronement propre à chaque exécution

On a ici des pages complexe avec des composants custom qui utilisent du javascript en veux-tu en voilà, on est capable de les tester avec selenium

seule contrainte, on s'assure que le browser démarre bien sur une nouvelle session à chaque fois. Comme on pilote par JUnit selenium, on a simplement le setup qui demande a selenium un nouveau profil à chaqe exécution

[*alexandre*]

peut être qu'il s agit d'une limitation du plugin de firefox je testerai le framework quand j'en aurai le temps et que le client sera d'accord ...

[tchize_]

c 'est surtout qu'il faut nettoyer ce que le plugin enregistre certains appels doivent etre simplifiés pour qu'ils marchent dans tous les cas. Dans l'absolu, le plugin firefox joue exactement de la meme manière que selenium server.

[*alexandre*]

c 'est surtout qu'il faut nettoyer ce que le plugin enregistre certains appels doivent etre simplifiés pour qu'ils marchent dans tous les cas. Dans l'absolu, le plugin firefox joue exactement de la meme manière que selenium server.

tu entends quoi par nettoyer ? la séquence de click et d attribut basé sur l id

[tchize_]

pour le host de départ, parfois faut le rendre plus générique. Comme en jsf il y a des session bean, il faut s'assurer qu'il soient, lors du rejeu, exactement dans le meme état qu'ils n'étaient au départ (et le plus simple c'est de s'assurer qu'on démarre toujours avec une nouvelle session, donc en virant à chaque fois les cookies ^^). Si t'as beaucoup de code généré en ajax, mettre de délais dans le rejeu, pour s'assurer que le ajax a le temps de s'exécuter (par défaut, l'enregistreur ne met des délais que sur le requetes). Sinon, tu va courir le risque que le rejeu aille plus vite que ton serveur et te dise qu'il trouve pas ses trucs