J'écris un analyseur pour analyser CSS.
J'ai commencé par modifier le grammaire de référence CSS , à utiliser la grammaire et Lexer Syntaxe est pris en charge par le outil de générateur d'analyseurs 3RD-Party que j'utilise.
Je pense que j'ai fini de coder la grammaire: le groupe d'analyseur est capable de générer des tables de transition d'état pour / de ma grammaire.
Le résultat (la sortie de l'analyseur-générateur) est d'environ 116 "règles", qui correspondent à 116 cas dans une instruction (code>. Des exemples de ces états de règles / commutateurs sont les suivants:
Le générateur d'analyseur a fait tout ce qu'il peut pour moi, et maintenant je commence à écrire (à la main) les différents cas des relevés de commutation, qui construiront ce que les gens appellent que les gens appellent un «syntaxe abstrait».
Ma question est de savoir comment tester cela. Je pense que ce que je veux, c'est un ensemble de fichiers CSS qui exercent diverses combinaisons et possibilités: par exemple. un fichier CSS qui spécifie un chariau; un autre fichier qui ne spécifie pas de caractères; c.
est là général un moyen de générer automatiquement cet ensemble de données d'entrée, pour une grammaire arbitraire ou un ensemble de règles?
Alternativement, existe-t-il un ensemble de fichiers spécifiquement CSS, dont le but est de couvrir la combinaison et les possibilités autorisées par la grammaire CSS standard?
N'hésitez pas à commenter aussi si je pars tout cela mal.
Pour le moment, je n'ai pas besoin de:
fichiers pour tester la manipulation de entrée illégale (c'est-à-dire des fichiers qui ne sont pas conformes à la grammaire)
essai de la manière dont divers navigateurs rendu basés sur leur l'analyse de CSS
3 Réponses :
Microsoft a défini un ensemble de plusieurs milliers de tests CSS pour la conformité IE8 avec la spécification CSS. http://samples.msdn.microsoft.com/ietestCenter/css.htm
Bien qu'ils soient concentrés sur la conformité du navigateur de test, vous pouvez éventuellement les adapter.
Il y a aussi les plus anciennes suites de test W3C, qui ne sont pas aussi complètes, mais pourraient servir votre objectif: http://www.w3.org/style/css/test/ < / p>
Le lien Microsoft est mort
Un contexte de grammaire sans contexte propose implicitement un ensemble infini d'arbres (parse). Chaque arbre proposé a un ensemble de feuilles qui rendent une phrase concrète dans la langue acceptée par cette grammaire. En explorant l'ensemble des arbres proposés (par exemple, en développant chaque non-déterminé selon ses alternatives possibles), vous pouvez générer une instance arbitraire de la langue. Vous pouvez générer un ensemble de tests en marchant sur les propositions d'arbres et en faisant des choix aléatoires. Une approche plus ciblée serait d'utiliser la recherche d'approfondissement itératif pour générer des phrases ordonnées par taille. Avec tout grammer intéressant, vous êtes susceptible d'obtenir un grand nombre d'instances, mais bon, c'est ce que les tests automatisés sont pour.
Ce que je ne ferais pas, c'est générer de telles phrases de votre grammaire de production, car les phrases que vous générez seront, par définition, celles qu'elle accepte: - {Ce que vous devriez faire est de construire votre générateur de phrase à l'aide de référence grammaire, pour exploiter le fait que vous ce qu'il accepte et ce que vous avez mis en œuvre pourrait être différent.
Avec ma grammaire, j'ai environ 55 non-terminaux. Si je l'évalue en tant qu'alser descendant, la méthode associée au non-terminal de niveau supérieur invoque des méthodes associées à des non-terminaux de niveau inférieur, et ainsi de suite. Chaque méthode de non-terminal invoque environ 1 à 3 méthodes de niveau inférieur (via une instruction dans la méthode), et est invoquée par 1 ou parfois 2 méthodes de niveau Higer. Ce serait quelque chose de simplement obtenir une couverture de code complète: pour vous assurer que toutes les possibilités sont testées au moins une fois (n'espérant pas chaque combinaison de toutes les possibilités), ...
... ce qui pourrait prendre sur l'ordre de (55 x 3 =) 150 cas de test. Je pense que je suis d'accord avec vous qu'il y a peu à gagner en générant automatiquement ces cas de test de la grammaire. J'ai toutefois demandé parce que je n'ai jamais été officiellement informé de l'analyse de l'école, tandis que d'autres personnes étaient: et je me demandais si vous avez été enseigné s'il existe un algorithme bien connu [S] pour tester les analyseurs.
Personne ne m'a appris à tester un analyseur, à l'école ou à l'extérieur. Juste pas dans le curriculum. J'entraîne beaucoup d'entre eux, mais surtout compter sur des zillions de cas de test du code réel, car la référence de référence de la plupart des compilateurs ne correspond pas à ce que les gars du compilateur ont vraiment mis en œuvre (Témoin Microsoft et C #; ils ont traversé la peine d'obtenir une standard, et ne l'a pas impliqué!). Vous semblez avoir de la chance d'avoir une vraie grammer de référence.
... En ce qui concerne de nombreux cas de test, vous pouvez simplement cesser de les générer lorsque vous avez «suffisamment» si vous n'obtenez pas une couverture complète. Si vous utilisez le schéma d'approfondissement itératif, vous pouvez vous arrêter avec un million de cas de test et être à peu près sûr avoir une bonne couverture: -} Cela ne prendra pas longtemps pour fonctionner.
4 ans de retard pour op mais SIMONSAPIN / CSS-analyse tests semble être une suite de test décente pour les analyseurs.