Spécification est important - cette déclaration est clair pour tout le monde. Un produit largement utilisé, de 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 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.
l'élaboration de tests de conformité consiste à identifier les affirmations contenues dans un cahier des charges, l'écriture des tests de conformité qui vérifient les assertions identifiés et reliant le test à l'affirmation selon laquelle il teste. Commençons par les points suivants: - L'affirmation est marquée - L'affirmation réelle est difficile de voir dans les spécifications (actuellement il n'y a que l'affirmation de petit gif à la fin de chaque affirmation) - Assertions complète ne sont consultés par la lecture du html directement ou regarder chaque test - Début de la affirmations sont difficiles à voir dans le code html - Fournir un moyen visuel pour afficher l'affirmation est facilement le problème que nous tentons de résoudre.
La principale est de couleur les affirmations (texte cahier des charges proprement dit) en utilisant des balises HTML. La recherche a été faite qui balises HTML à utiliser. Div, span, table et balises de police ont été examinées. La meilleure solution est la balise de police. Ainsi, le texte est entouré de balises de police. L'attribut class de la balise de police correspond au type de l'affirmation. Fe si le asserion est nouveau, il est de couleur rouge, pour indiquer que les tests doivent être écrites, les affirmations anciennes sont colorés en vert pour indiquer que les tests existent déjà. Il devrait y avoir un utilitaire (script ou un programme java) pour balayer marqué cahier des charges et d'ajouter automatiquement les balises nécessaires pour la coloration. La couleur de fond du texte sera déterminé par la couleur attribut title de l'affirmation. Cette méthode a été appliquée et fonctionne correctement. Aux fins de facilité d'utilisation, il devrait y avoir un mécanisme pour cacher les colorants, Fe un javascript.
Un inconvénient de cette solution est que la couleur est statique car elle est basée sur l'attribut title. Une deuxième solution serait que l'outil vérifier une existence d'un test (basé sur l'ID affirmation ou un lien dans l'affirmation). Si il existe un test, nous ferions quelque chose pour régler la couleur de cette affirmation. Il pourrait être aussi simple que la fixation d'un attribut title. Un inconvénient de cette solution serait que la coloration affirmation serait encore statique, mais sur la base lorsque l'utilisateur exécuter les scripts.
Une variante de la solution donnée est que nous générer dynamiquement les données de couverture lorsque la spécification est visualisé dans un navigateur. Nous déterminer si un test existe dans le répertoire de test pour une affirmation donnée et la couleur l'affirmation en conséquence. Cela pourrait se faire grâce à un javascript / vbscript en utilisant des objets, qui permettent l'accès aux systèmes de fichiers. Cette méthode serait dynamique et devrait toujours avoir le dernier état affirmation de couverture.
Voici quelques exemples de JLS3 chapitres "Conversions et promotions" et "interfaces":
Assertions conv063, conv047, conv065, conv48, conv66 et conv049 est de la version précédente du SPEC, ils n'ont pas été modifiées et mise à jour des tests n'est pas nécessaire - de couleur aigue-marine est (vert neurtal). Conv155 et conv156 sont nouveaux, de nouveaux tests devraient être développés, les affirmations sont colorés en rouge éclatante. Conv064 a été modifié, mise à jour de test est nécessaire - de couleur orange. Annot019 est un nouveau, des tests existent, mais ils sont nécessaires pour être changé - couleur saumon. Annot020 est nouvelle, mais кудумфте tests existent - de couleur vert clair.
Le principal avantage de la coloration spec est que la spécification est visualisé. L'utilisateur peut voir l'affirmation entier et son titre. On peut dire en regardant les spécifications, où il ya des zones où la couverture est faible et où certains lots ou des tests devraient être ajoutés ou modifiés. Il est essentiellement la possibilité de voir à quel point une spécification est marqué et la façon dont il est testé.
Il est très important d'avoir un bon processus tout en écrivant la suite de test. Je vais parler de celle qui a été utilisé pour JLS.
Tel que mentionné précédemment 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 consiste à identifier tous les assertions dans les spécifications. Après que le développeur peut écrire des tests.
Exemple d'affirmations de la Java Specification Language:
Une erreur de compilation se produit si le modificateur même apparaît plusieurs fois dans une déclaration d'interface.
Le nom de l'exécutable d'un type de membre se compose du nom de son binaire immédiatement joint type, suivi par $, suivi par le simple nom du membre.
Une instruction continue peut se produire que dans un certain temps, faire, ou pour la déclaration.
Il pourrait y avoir de nombreuses déclarations qui ne sont pas vérifiables ou qui impliquent l'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:
Nous ne recommandons pas cette "notation mixte» pour les déclarations de tableau.
Les situations où la classe d'un objet n'est pas statique connu peut conduire à des erreurs de type run-time.
Si, toutefois, l'évaluation d'une expression lève une exception, alors l'expression est dit pour terminer brusquement.
Il ya de nombreux débats et conflits 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 résumé de la parole. La fin d'ancrage était une image et un lien vers le test. L'opinion HTML et l'affichage de code sont présentés sur les illustrations correspondantes. L'affirmation d'identité 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 de test qui est la 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 genre 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 de migrer 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.
Spécification est important - cette déclaration est clair pour tout le monde. Un produit largement utilisé, de 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. 
