La banc de test de sableCC a ete divise en deux parties. Les tests qui dont les transformations sont completement induites par le logiciel donc implicites et les tests dont les transformations sont specifiees explicitement par le developpeur. Nous nommerons ces dernieres tests explicites. Description des tests implicites : Essentiellement les operateurs ont ete teste. Cela est normal du fait que ce ne sont que les operateurs qui induisent des transformations non intuitives. Nous entendons par transformations non intuitives les tranformations qui non seulement sont rajoutees par le logiciel dans l'arbre syntaxique a cause d'absence de transformaions explicites mais aussi tranformation du a la presence d'operateurs. En illustration, si nous prenons la production suivante : prod = element1 element2; Cette production est transformee par sableCC en prod -> prod = element1 element2 -> New prod(element1, element2). Par contre la meme production avec un operateur * par exemple : prod = [premier]:element* [second]:element; serait transformee en prod -> prod = [second]:element -> New prod(Null, second) | Xelement [second]:element -> New prod(Xelement.element second); Xelement -> element* = {first} element -> (element) | {second} element Xelement -> (element Xelement.element) ; Remarquez dans le cas ci dessus, l'ajout d'une production Xelement. Elle sert a mettre en oeuvre l'operateur *. Elle est aussi utilisee dans le cas du +. Mais nous nous passerons de la description de l'operateur + ici. Elle sera decrite dans le document final incluant un manuel d'utilisation du logiciel. A present que la lumiere est faite sur la distinction que nous faisons entre tests implicites et tests explicites, nous pouvons proceder a la description des tests proprement dits. Nous avons d'abord teste un seul type operateur. Pour ce faire, nous avons couvert le squelette en envisageant les cas de figure ci apres : - l'operateur apparait une fois dans la production - l'operateur apparait deux fois dans la production - l'operateur apparait trois fois dans la production Et pour chacun de cas, nous avons degage les differentes possibilites qu'on avait. Ainsi avec une seule apparition dans la production et explorant les differents cas de figure, nous sommes arrives a 4 tests differents. Pour le * par exemple, ca donne : 1- prod = t1*; 2- prod = ti t2*; 3- prod = ti* t2; 4- prod = ti t2* t3; Dans les productions ou l'operateur apparait deux fois, on obtient 8 possibilites : 1- prod = t1* t2*; 2- prod = t1 t2* t3* ; 3- prod = t1* t2 t3* ; 4- prod = t1* t2* t3 ; 5- prod = t1 t2* t3 t4* ; 6- prod = t1 t2* t3* t4 ; 7- prod = t1* t2 t3* t4; 8- prod = t1 t2* t3 t4* t5; Et finalement pour un operateur qui apparait trois fois dans la production, nous obtenons 16 possibilites donc 16 tests differents : 1- grammar = tar* id* digit*; 2- grammar = minus tar* id* digit*; 3- grammar = tar* id* digit* minus; 4- grammar = tar* minus id* digit*; 5- grammar = tar* id* minus digit*; 6- grammar = l_bkt tar* r_bkt id* digit*; 7- grammar = l_bkt tar* id* r_bkt digit*; 8- grammar = l_bkt tar* id* digit* r_bkt; 9- grammar = tar* l_bkt id* r_bkt digit*; 10- grammar = tar* l_bkt id* digit* r_bkt; 11- grammar = tar* id* l_bkt digit* r_bkt; 12- grammar = l_bkt tar* minus id* r_bkt digit*; 13- grammar = l_bkt tar* minus id* digit* r_bkt; 14- grammar = l_bkt tar* id* minus digit* r_bkt; 15- grammar = tar* l_bkt id* minus digit* r_bkt; 16- grammar = l_bkt tar* to id* minus digit* r_bkt; Nous avons donc par operateur 4+8+16 tests, c'est a dire 28 tests ce qui fait un total de 84 (3 operateurs differents : *, +, ?) pour les tests avec un seul type d'operateurs. La deuxieme partie des tests implicites s'interessent a la combinaison des operateurs. Nous avons teste le cas du mixage de deux operateurs puis de trois dans un ordre predetermine. Nous avons remarque que le cas de deux operateurs differents revenait exactement a un meme operateur qui apparait deux fois dans la meme production. Il en resulte donc que pour deux quelconques operateurs, nous obtenons 8 tests differents. Pour 2 operateurs, nous avons teste les combinaisons : plus qmark (8 tests) plus star (8 tests) star qmark (8 tests) Le cas de qmark star qmark plus et star plus n'ont pas ete aborde ici car ils sont implicitement couvert dans le cas de la combinaison unique de trois operateurs; laquelle est : qmark star plus (16 tests engendres). Au total, pour les tests implicites, nous arrivons donc a 84+24+16 ce qui fait 124 tests. **** Description des tests explicites : Comme l'indique le titre, les tests explicites concernent essentiellement les transformations que l'usager specifie explicitement dans la grammaire. Il y a quatre types de transformations possibles que nous appelerons alt_transform_term : - le New nomalternative() : pour creer un nouveau noeud dans l'arbre syntaxique. - element : pour recuperer un noeud se trouvant deja dans l'arbre. - (elem1 elem2 ...) : pour creer une liste d'elements de meme type. Les elements qui se retrouvent dans la liste sont soit des elements(noeuds ou tokens) qui etaient deja dans l'arbre, soit des nouveaux noeuds crees. - Null : pour eliminer un element(noeud ou token) dont on ne voudrait pas tenir compte dans certains cas. Pour couvrir le squellette complet de ces transformations, nous avons d'abord teste ces differentes transformations individuellement, et ensuite procede au mixage de transformations entre elles. Pour les tests individuels, nous avons surtout voulu voir ce qu'on pouvait obtenir a travers les divers cas de figure possible. Nous sommes loin de pretendre tout tester meme dans des cas aussi cibles; ceci etant une analyse profonde du probleme nous montre que notre approche est valable. &&& Tests individuels &&& Nous procedons en testant une seule apparition du alt_transform_term dans la transformation, ensuite deux, puis trois. Remarquez, c'est un peu la meme approche que nous avons utilise dans le cas des transformations implicites. Et cette approche peut varier dependemment du type de alt_transform_term utilise. Ainsi pour le New par exemple, il est interessant de tester le cas ou le nouveau noeud construit ne prend aucun argument ( New alternative() ), un seul argument ( New grammar(elem) ) ou deux arguments (New grammar(elem1 elem2)). Mais on peut aussi comme stipuler plus haut tester le cas ou le New apparait 1, 2 ou 3 fois dans la meme transformation. Dans le premier cas, la production qui fait ressortir la transformation pourrait ressembler a : 1- prod = tar? -> New prod(); ou prod = tar? -> New prod(tar) ou prod = tar? minus -> New prod(tar, minus) prod = tar? minus id -> New prod(tar, minus, id) Dans le deuxieme cas, on aurait par contre quelque chose du genre : 2- prod = P.tar? -> New prod.notvide(P.tar.tar, P.tar.pid, P.tar.psemicolon); tar -> P.tar pid psemicolon = T.tar id semicolon -> New tar(T.tar) New pid(id) New psemicolon(semicolon); avec tar, pid et psemicolon des productions de la section AST de la grammaire. (voir les fichiers new1.grammar a new4.grammar pour une description complete de ces tests). Pour les listes (), la meme approche a ete adoptee.(les fichiers list1.grammar a list4.grammar contiennent les tests complets). Par contre en ce qui concerne les alt_transform_term Null et element, par analogie a l'approche utilisee precedemment, seul le cas 2 a ete teste. C'est d'ailleurs normal car ces alt_transform_term ne prennent aucun argument. Nous en donnons une breve illustration ici : 1- prod = tar? -> Null; prod -> tar id = tar? -> Null Null; prod -> tar = tar? -> tar; prod -> tar id = tar? id -> tar id; (voir les fichiers simple1.grammar a simple4.grammar et null1.grammar a null4.grammar pour une description complete de tests des alt_transform_term element et Null). &&& Tests combines &&& L' approche est surtout basee sur le nombre de alt_transform_term combines. Etant donne que nous en avons quatre differents, nous avons d'abord fait le mixage de deux, puis trois et enfin quatre. Il a fallu dans ces cas trouver une methode qui nous permette de tout tester sans avoir a ecrire les nombreuses combinaisons possibles et imaginables(ex: pour 4, on a 4^4 = 256). Dans le mixage a deux alt_transform_term, on 6 possibilites car cela revient a faire une combinaison de deux elements differents dans un ensemble ou il y en a quatre. Par exemple pour la combinaison : New list, nous faisons les tests suivants : New list list New list New list New list New. Nous avons juge non necessaire de tester des cas comme {New New list}, {New list New list} car ils sont implicitement couvert par les combinaisons de tests individuels et de certains mixages. Pour le cas de trois alt_transform_term, nous avons d'abord enumere les differents cas possibles en partant d'un alt_transform_term de depart et ensuite, nous avons trouve une transformation de deux mixages dont deux termes de notre cas s'y trouvaient deja. Ainsi pour la combinaison {list New Id}, nous partons de la transformation a deux alt_transform_term {list New} auquel nous rajoutons un Id a la fin pour obtenir une transformation a trois alt_transform_term. Il est a noter que le mixage de trois alt_transform_term se fait de facon ordonnee mais toutes les combinaisons n'ont pas ete teste car l'engin de generation de code procede de la meme maniere dans les deux cas.