La più semplice definizione di metadati è che si tratta di dati sui dati. I metadati possono essere molto utili. Quanto al markup c'era qualche metadati incorporati: id, descrizione piccoli di affermazione, il link al test. Durante il trasferimento markup mi sono reso conto che più i metadati sarebbe molto utile. Nella nuova versione della specifica c'erano vari tipi di asserzioni:
di età: testo non modificato, le prove non hanno bisogno di eventuali modifiche;
oldToBeChanged: testo cambiato, le prove hanno bisogno di essere cambiato;
nuovo: totalmente nuovo testo, nuove prove necessarie;
newWritten: nuovo testo, ma i test già esistenti (perché il processo di sviluppo di test iniziata non appena il progetto di spec era disponibile);
newWrittenToBeChanged: nuovo testo, le prove esistono, spec progetto modificato, in modo i test devono essere cambiate o prove esistenti non sono sufficienti.
L'aggiunta di questo tipo di dati al markup semplificherebbe notevolmente il lavoro futuro - lo sviluppo di test. Perché solo guardando una affermazione in quella specifica può facilmente dire se sono necessari più test o di più dovrebbe essere aggiornato.
Con il dato architettura markup è stato deciso di utilizzare l'attributo title nel tag href-bis (la seconda ancora). Quindi il codice sarà simile:
<a name=assertionID> <! - descrizione shord come commento html -> affermazione dichiarazione qui <a href="path src="pics/assert.gif"> a title=assertType> ID test" prova che è la stessa affermazione ID </ a>
L'attributo title possono essere visualizzati in un browser come un suggerimento.
E 'molto importante avere un buon processo di scrittura, mentre la suite di test. Parlerò 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 ', fanno, o per la dichiarazione.
Ci potrebbero essere molte affermazioni che non sono verificabili o delle incertezze. 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. Questa impostazione è stata scelta per la lingua di la 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 più semplice definizione di metadati è che si tratta di dati sui dati. I metadati possono essere molto utili. Quanto al markup c'era qualche metadati incorporati: id, descrizione piccoli di affermazione, il link al test. Durante il trasferimento markup mi sono reso conto che più i metadati sarebbe molto utile. Nella nuova versione della specifica c'erano vari tipi di asserzioni: 
