La specifica è importante - questa affermazione è chiaro a tutti. Un prodotto largamente utilizzato, la tecnologia o la lingua senza una specifica è inutile. Una specifica senza testsuite è pericoloso. Un testsuite senza markup e le prove è impossibile. Questo processo è abbastanza complessa. Tuttavia ci sono modi per semplificare la fase di marcatura.
Per quanto riguarda Java Language Specification (JLS) e (JVM) che sono scritte in FrameMaker. In seguito di specifica è esportato in html e pdf. Il markup è incorporato in versione html. La mia opinione è che le informazioni di markup deve essere posizionato in (o connesso con) il testo d'origine. Nel nostro caso è documento FrameMaker. Non sono sicuro che questo è possibile a tutti, ma la mia ipotesi è. In caso contrario, FrameMaker forse non è la soluzione migliore. Come risultato si ridurrà notevolmente la quantità di tempo e fatica necessari per il trasferimento di markup vecchie e la marcatura su nuovo testo. Inoltre durante la stesura della prossima revisione della specifica l'autore insieme al gruppo TCK dovrebbe markup tutti chenged e nuove affermazioni. Direi che il modo migliore è quando la scrittura e le specifiche tecniche dei processi di markup sono fatti allo stesso tempo. E 'ragionevole per l'autore a sottolineare gli sviluppatori di test che le dichiarazioni devono essere testati.
E 'molto importante avere un buon processo di scrittura, mentre la suite di test. Voglio parlare di quello che è stato utilizzato per JLS.
Come già detto prima che il prodotto finale è il numero di prove. C'è una relazione tra i test e le specifiche. Il processo di affermazione-driven dà un'idea di ciò che ogni gruppo di prove effettivamente i controlli nella specifica. L'utilizzo di questo rapporto lo sviluppatore può calcolare la copertura, ottiene l'elenco delle affermazioni su cui le prove non sono state scritte, ecc
Affermazione è una dichiarazione da una specifica che può essere provata. E il primo passo è quello di individuare tutte le asserzioni nel disciplinare. Dopo di che lo sviluppatore può scrivere dei test.
Esempio di quanto affermato dal Java Language Specification:
Un errore in fase di compilazione si verifica se il modificatore stesso appare più di una volta in una dichiarazione di interfaccia.
Il nome di un tipo binario membro è costituito dal nome del suo binario immediatamente racchiude tipo, seguito da $, seguito dal nome semplice dei membri.
A continuare dichiarazione può avvenire solo in un po ', fare, o per la dichiarazione.
Ci potrebbero essere molte affermazioni, che non sono controllabili o comporta incertezza. A volte tali dichiarazioni comprendono termini quali "possibile" o "forse". Non è vero che se una frase è una parola "può" non è verificabile, ma di solito è così.
Esempi di dichiarazioni non verificabili:
Si consiglia di non tali "notazione misti" per le dichiarazioni di array.
Situazioni in cui la classe di un oggetto non è staticamente conosciuta, può portare ad errori di tipo run-time.
Se, tuttavia, la valutazione di un'espressione genera un'eccezione, quindi l'espressione è detto per completare bruscamente.
Ci sono molte discussioni e controversie su asserzioni. Alcuni dicono che esempi non devono essere trattati come asserzioni. Altri dicono che ogni affermazione è un affermazioni e ci sono due tipi di esse: verificabili e non verificabili. La mia opinione personale è che un 'affermazione è certamente qualcosa di verificabile. E nella maggior parte dei casi sono esempi di affermazioni solo perché il test può essere scritta controllando l'esempio particolare.
Il processo di identificazione affermazioni del disciplinare è chiamato markup. Ci sono molteplici approcci. Ma in ogni caso l'utente deve essere in grado di ottenere informazioni su se la dichiarazione è un'affermazione e in qualche modo distinguere una affermazione da un altro. Ci potrebbe essere un repository separato con mappatura delle affermazioni e la loro identità di dichiarazioni. Mi piace l'idea di integrare il codice nelle specifiche. Questo approccio è stato scelto per la lingua del Java SE suite di test. Il GLS è stato scritto in FrameMaker. Con meccanismi di esportare la versione PDF e HTML sono state create. La versione HTML è stato utilizzato durante la creazione della suite di test.
In JLS JLS e 2 alcune ancore individuato l'inizio e la fine di una affermazione. Ulteriori informazioni sono state la assertionID e breve sintesi della dichiarazione. La fine di ancoraggio è un immagine e un link per il test. La visualizzazione HTML e la visualizzazione di codice sono da figura corrispondente. L'ID affermazione sono arr033, arr034, arr020, ecc
L'idea generale può essere descritto come:
<a name=assertionID> <! - descrizione shord come commento html -> affermazione dichiarazione qui <a href="path src="pics/assert.gif"> a test"> ID test, che è la stessa affermazione ID </ a>
Se il bilancio separato in diverse parti del disciplinare sono testati da un test il primo tag sarà qualcosa del tipo arr033_0, arr033_1, arr033_2.
Questo tipo di architettura è stato utilizzato per JLS JLS e 2. E 'stato leggermente modificato per JLS3, ma l'idea principale è stata mantenuta. So che alcuni esempi di approcci con ID affermazione non statico conservati in un archivio separato, dove ID è un valore hash calcolato in base al contenuto. Per vari motivi ha dimostrato fino ad essere non una soluzione molto buona. C'è sempre un processo difficile la migrazione alla nuova versione della specifica. Ma a mio parere è molto più facile con l'ID statico embedded nelle specifiche.
La specifica è importante - questa affermazione è chiaro a tutti. Un prodotto largamente utilizzato, la tecnologia o la lingua senza una specifica è inutile. Una specifica senza testsuite è pericoloso. Un testsuite senza markup e le prove è impossibile. Questo processo è abbastanza complessa. Tuttavia ci sono modi per semplificare la fase di marcatura. 
