Assertion.ru

L'ensemble du processus de création d'un balisage et le développement de tests prend du temps. Et quand il semble que le travail est fait, une nouvelle version du spec est libéré. Qu'est-ce qui se passe ensuite? Bien sûr, il ya un besoin d'une nouvelle version de la suite de test. De nouveaux tests doivent être écrites et les anciennes mises à jour ou même supprimé.

La meilleure façon de commencer est de faire le balisage. Cette tâche peut être divisée en deux sous-groupes:

• transfert de balisage vieux de la spec précédente à la nouvelle spécification (ceci est nécessaire car de nombreux tests ont déjà été écrites, elles sont liées à id Spec, en réutilisant tous les tests possibles, c'est une bonne idée);
• balisage et de nouvelles affirmations mise à jour.

Transférer le balisage est assez simple de le faire à la main:

1. Recherchez la balise de balisage dans les spécifications du vieux.
2. Trouver le meilleur endroit pour insérer la balise dans la nouvelle version de la spécification.
3. Insérez la balise.

Si il ya seulement 10 affirmations - ce travail est un morceau de gâteau. Mais si il ya des milliers C'est un travail dur qui doit être automatisée. Le plus difficile est de trouver un nouveau lieu approprié pour des balises. Il est difficile de simplement parce que la spécification a été modifiée. Pour JLS2 au processus de migration JLS3 l'alrorithm flollowing a été utilisée:

Chaque affirmation est arrondie avec des ancres HTML. Deux d'entre eux devraient être transférés en utilisant l'algorithme tel.

Adopter algorithme pourrait être utilisé à la fois en ignorant les balises HTML et profiter d'eux. Algorithme est valable pour les spécifications écrites en texte brut, HTML ou XML.

Cet algorithme a été mis en œuvre dans JLS2-> outil de marquage transfert JLS3. 84% des balises ont été transférés automatiquement. Le reste d'entre eux ont été effectuées manuellement.

Comme mentionné avant que le produit final est le nombre de tests. Il existe une relation entre les tests et le cahier des charges. Le processus axé sur l'affirmation donne une idée de ce que chaque groupe d'analyses effectivement des contrôles dans le cahier des charges. En utilisant cette relation le développeur peut calculer la couverture, obtenir la liste des affirmations sur lequel les essais n'ont pas été écrites, etc

L'affirmation est une déclaration d'un cahier des charges qui peuvent être testés. Et la première étape consiste à identifier toutes les affirmations contenues dans le cahier des charges. Après que le développeur peut écrire des tests.

Exemple d'affirmations de la Java Specification Language:

Il pourrait y avoir de nombreuses déclarations qui ne sont pas testables ou une incertitude. Parfois, de telles déclarations comprennent des termes comme «possible» ou «peut-être». Il n'est pas vrai que si une phrase a un mot «peut», il n'est pas vérifiable, mais habituellement il en est ainsi.

Exemples de déclarations non vérifiables:

Il ya de nombreuses discussions et les différends au sujet des affirmations. Certains disent que les exemples ne doivent pas être traités comme des affirmations. D'autres disent que chaque instruction est une des affirmations et il ya deux sortes d'entre eux: vérifiables et non vérifiables. Mon opinion personnelle est que l'affirmation est certainement quelque chose de vérifiable. Et dans la plupart des cas sont des exemples affirmations simplement parce que le test peut être écrite vérifier l'exemple particulier.

Le processus d'identification des affirmations contenues dans le cahier des charges est appelée majoration. Il existe plusieurs approches. Mais en tout cas, l'utilisateur doit être en mesure d'obtenir des informations indiquant si la déclaration est une affirmation et en quelque sorte distinguer une affirmation d'un autre. Il pourrait y avoir un dépôt séparé avec la cartographie d'affirmations et de leur carte d'identité à des déclarations. J'aime l'idée d'intégrer le balisage dans le cahier des charges. Cette approche a été choisie pour la région de langue de la version Java SE suite de test. Le JLS a été écrit dans FrameMaker. Avec des mécanismes d'exportation du format PDF et HTML ont été créés. La version html a été utilisé lors de la création de la suite de test.

En JLS et JLS 2 quelques ancres spéciales identifié le début et la fin d'une affirmation. informations complémentaires ont été l'assertionID et bref résumé de la déclaration. La fin d'ancrage était une image et un lien vers le test. L'affichage HTML et la vue de code sont indiqués sur les illustrations correspondantes. L'affirmation d'identité ne sont arr033, arr034, arr020, etc

L'idée générale peut être décrite comme suit:

<a name=assertionID> <! - description shord en commentaire html ->
déclaration affirmation ici
<img href="path <a src="pics/assert.gif"> à test"> ID d'essai qui est le même que l'affirmation d'identité </ a>

Si des états distincts dans différentes parties du cahier des charges sont testées par un test de la première balise sera quelque chose comme arr033_0, arr033_1, arr033_2.

Ce type d'architecture a été utilisée pour JLS et JLS 2. Il a été légèrement modifiée pour JLS3, mais l'idée principale a été conservée. Je sais que certains des exemples d'approches avec les identifiants de l'affirmation de non-statique conservés dans un dépôt séparé, où ID est une valeur de hachage calculée en fonction du contenu. Pour diverses raisons, il a montré à ne pas être une très bonne solution. Il ya toujours un processus difficile la migration vers la nouvelle version de la spécification. Mais, à mon avis, il est beaucoup plus facile avec l'ID statique est-elle intégrée dans le cahier des charges.