Spécification est important - cette déclaration est clair pour tout le monde. Un produit largement utilisé, la technologie ou de la langue sans un cahier des charges est inutile. Un cahier des charges sans testsuite est dangereux. Une suite de tests, sans majoration et de tests est impossible. Ce processus est assez complexe. Toutefois, il existe des moyens de simplifier l'étape de balisage.
Quant à la spécification en langage Java (JLS) et (JVM) elles sont écrites dans FrameMaker. Ensuite spec est exporté au format HTML et PDF. Le balisage est intégré en version html. Mon opinion est que des informations de marquage doivent être placés dans (ou en relation avec) le texte d'origine. Dans notre cas, il s'agit d'un document FrameMaker. Je ne suis pas sûr que cela est possible à tous, mais je pense qu'il est. Si non, peut-être FrameMaker n'est pas la meilleure solution. En conséquence, nous permettra de réduire considérablement la quantité de temps et les efforts nécessaires pour le transfert de balisage ancien et le marquage de nouveau texte. En outre, durant l'écriture de la prochaine révision de la spécification de l'auteur avec l'équipe de tck devrait balisage tous les chenged et de nouvelles affirmations. Je dirais que la meilleure façon, c'est quand la rédaction de spécifications et les processus de balisage sont fait en même temps. Il est raisonnable pour l'auteur de souligner les développeurs à tester les états financiers qui doivent être testés.
La définition la plus simple de métadonnées, c'est que ce sont les données sur les données. Les métadonnées peuvent être très utiles. En ce qui concerne le balisage y avait une certaine métadonnées intégrées: id, petite description de l'affirmation, le lien pour tester. Pendant le transfert de balisage, j'ai réalisé que plus de métadonnées serait très utile. Dans la nouvelle version de la spécification, il y avait plusieurs sortes d'affirmations:
anciens: texte non-changé, les tests n'ont pas besoin de tout changement;
oldToBeChanged: texte modifié, les tests ne doivent être modifiées;
nouvelles: totalement nouveau texte, de nouveaux tests nécessaires;
newWritten: nouveau texte, mais les tests existent déjà (parce que le processus d'élaboration d'essai a commencé dès que les spécifications du projet de disposition);
newWrittenToBeChanged: nouveau texte, des tests existent, spec projet changé, les tests doivent être modifiées ou des tests existants ne suffisent pas.
L'ajout de ce type de données en langage de balisage simplifierait grandement les travaux futurs - le développement d'essai. Parce que, tout en regardant une assertion dans le spec peut facilement dire si d'autres tests sont nécessaires ou plusieurs devraient être mis à jour.
Avec la donnée architecture balisage est a été décidé d'utiliser l'attribut title dans la balise href (la deuxième ancre). Ainsi, le balisage ressemblerait à ceci:
<a name=assertionID> <! - description shord en commentaire html -> déclaration affirmation ici <img href="path <a src="pics/assert.gif"> à title=assertType> ID test test" qui est le même que l'affirmation d'identité </ a>
L'attribut title peut être visualisé dans un navigateur comme un indice.
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:
Recherchez la balise de balisage dans les spécifications du vieux.
Trouver le meilleur endroit pour insérer la balise dans la nouvelle version de la spécification.
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.
Hin 1T: si certains tag est transféré, il ya une grande possibilité, cette balise suivante dans Spec ancienne sera placé après celui qui est transféré.
Astuce 2: algorithme doit vérifier que la deuxième ancre doit être placé après la première et pas trop loin de là.
Regardez le texte avant et après la balise dans Spec vieux. Trouver dans les spécifications du nouveau. Si l'un d'eux a pas changé - la réponse est trouvée. habituellement la longueur devrait être 1-2 sentances, au moins 60 caractères. Si aucune ou plusieurs sentances trouvées - sauter cette étape.
Essayez de faire les mêmes que dans (1), mais supprimer toutes les balises HTML du texte qui entoure près de la balise. Si aucun trouvées - sauter cette étape.
Essayez d'adopter l'algorithme, qui essaye de trouver un texte semblable dans les spécifications du nouveau. un fichier. Suivez les étapes (1) et (2), mais desrease la durée de la recherche de texte dans une boucle jusqu'à ce que la phrase se trouve ou la durée est trop courte. Le travail pratique a montré que ce nombre ne devrait pas être inférieure à 20. b. Si les étapes (1) et (2), ou (3a) ont trouvé plusieurs sentances augmenter la longueur du texte à la recherche jusqu'à ce que le texte se trouve dans la spécification de nouvelles ou de la limite supérieure (Fe 140 caractères) est atteint. Utilisez des conseils pour trouver le meilleur texte correspondant.
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.
Spécification est important - cette déclaration est clair pour tout le monde. Un produit largement utilisé, la technologie ou de la langue sans un cahier des charges est inutile. Un cahier des charges sans testsuite est dangereux. Une suite de tests, sans majoration et de tests est impossible. Ce processus est assez complexe. Toutefois, il existe des moyens de simplifier l'étape de balisage. 
