La especificación es importante - esta afirmación es evidente para todos. Un producto ampliamente utilizado, la tecnología o el lenguaje sin una especificación es inútil. Una técnica sin un banco de pruebas es peligroso. Un banco de pruebas sin marcaje y pruebas es imposible. Este proceso es bastante complejo. Sin embargo, hay maneras de simplificar la etapa de marcado.
En cuanto a la especificación del lenguaje Java (JLS) y (JVM) que están escritos en FrameMaker. Después de especificaciones se exporta a HTML y PDF. El marcado se incrusta en versión html. Mi opinión es que la información de marcado debe ser colocado en (o relacionado con) el texto origen. En nuestro caso es el documento FrameMaker. No estoy seguro de que esto es posible en absoluto, pero creo que es. Si no, tal vez FrameMaker no es la mejor solución. Como resultado, reducirá significativamente la cantidad de tiempo y el esfuerzo necesarios para la transferencia de marcas viejas y marcar un nuevo texto. Por otra parte durante la grabación de la próxima revisión de las especificaciones del autor junto con el equipo tck debe marcado todas chenged y nuevas afirmaciones. Yo diría que la mejor manera es cuando la escritura de especificaciones y los procesos de marcado se realizan al mismo tiempo. Es razonable que el autor señala que los desarrolladores probar lo que las declaraciones deben ser examinados.
Es muy importante tener un buen proceso al escribir el conjunto de pruebas. Voy a hablar de la que se utilizó para JLS.
Como se ha mencionado antes que el producto final es el número de pruebas. Existe una relación entre las pruebas y de la definición. El proceso impulsado por la afirmación da una idea de lo que cada grupo de pruebas comprueba efectivamente en el pliego de condiciones. Utilizando esta relación el desarrollador puede calcular la cobertura, obtener la lista de afirmaciones sobre las que las pruebas no fueron escritos, etc
La afirmación es una declaración de un pliego de condiciones que pueden ser probadas. Y el primer paso es identificar todas las afirmaciones contenidas en el pliego de condiciones. Después de que el desarrollador puede escribir ensayos.
Ejemplo de las afirmaciones de la Java Especificación del lenguaje:
Un error en tiempo de compilación se produce si el modificador de la misma aparece más de una vez en una declaración de interfaz.
El nombre binaria de un tipo de miembro consiste en el nombre binario de sus inmediatamente adjuntando tipo, seguido de $, seguido por el nombre simple de los miembros.
Una sentencia continue se puede producir sólo en un rato, hacer o de declaración.
Podría haber muchas declaraciones que no son comprobables o se refieren a la incertidumbre. A veces tales declaraciones incluyen palabras como "posible" o "tal vez". No es cierto que si una frase tiene una palabra "podrá" no es comprobable, pero normalmente es así.
Ejemplos de declaraciones no comprobables:
No se recomienda como "notación mixta" para las declaraciones de matriz.
Situaciones en las que la clase de un objeto no es estática conocido puede dar lugar a errores de tipo en tiempo de ejecución.
Si, sin embargo, la evaluación de una expresión produce una excepción, entonces la expresión se dice que es completa abruptamente.
Hay muchas discusiones y controversias acerca de afirmaciones. Algunos dicen que los ejemplos no deben ser tratados como aserciones. Otros dicen que cada declaración es un afirmaciones y hay dos tipos de ellos: comprobables y no comprobables. Mi opinión personal es que una afirmación es ciertamente algo comprobable. Y en la mayoría de los casos son ejemplos afirmaciones sólo porque la prueba se pueden escribir cheques en particular el ejemplo.
El proceso de identificación de las afirmaciones en el pliego de condiciones se llama marcado. Existen muchos enfoques. Pero en cualquier caso, el usuario debe ser capaz de obtener información sobre si la declaración es una afirmación y de alguna manera distinguir una afirmación de otro. Podría haber un repositorio separado con el mapeo de las afirmaciones y sus id a declaraciones. Me gusta la idea de integrar el marcado en el pliego de condiciones. Este enfoque fue elegido para el área de lengua del Java SE serie de pruebas. El JLS fue escrito en FrameMaker. Con mecanismos de exportación de PDF y HTML fueron creados. La versión HTML se utilizó durante la creación de la serie de pruebas.
En JLS y JLS 2 algunas anclas especiales identificadas al inicio y al final de una afirmación. Información adicional fue el assertionID y breve resumen de la declaración. El fin de anclaje era una imagen y un enlace a la prueba. La vista HTML y en la vista de código se muestran en las ilustraciones correspondientes. El identificador de la afirmación son arr033, arr034, arr020, etc
La idea general se puede describir como:
<a name=assertionID> <! - Descripción shord como comentario HTML -> aseveración de los estados aquí <img href="path <a src="pics/assert.gif"> a prueba test"> ID que es lo mismo que la afirmación de identificación </ a>
Si las declaraciones por separado en diferentes partes del pliego de condiciones se ponen a prueba una prueba de la primera etiqueta será algo así como arr033_0, arr033_1, arr033_2.
Este tipo de arquitectura se utilizó para JLS y JLS 2. Se ha modificado ligeramente para JLS3, pero la idea principal era mantenerse. Sé que algunos ejemplos de enfoques con ID afirmación no estáticos mantenerse en un depósito separado, donde ID es un valor hash calculado basado en el contenido. Por varias razones que se presentaron para no ser una solución muy buena. Hay siempre un proceso difícil migrar a la nueva versión de la especificación. Pero en mi opinión es mucho más fácil con el identificador estático integrado en el pliego de condiciones.
La especificación es importante - esta afirmación es evidente para todos. Un producto ampliamente utilizado, la tecnología o el lenguaje sin una especificación es inútil. Una técnica sin un banco de pruebas es peligroso. Un banco de pruebas sin marcaje y pruebas es imposible. Este proceso es bastante complejo. Sin embargo, hay maneras de simplificar la etapa de marcado. 
