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 avremo una notevole riduzione della quantità di tempo e sforzo necessari per il trasferimento di markup vecchi e 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.
sviluppo di test di conformità implica l'identificazione affermazioni in un apposito disciplinare, scrivendo test di conformità che verificare le affermazioni identificati e che collega il test per l'affermazione che essa test. Iniziamo dai punti seguenti: - L'affermazione è segnato - L'affermazione reale è difficile vedere nelle specifiche (attualmente ci sono solo piccole gif affermazione alla fine di ogni affermazione) - Affermazioni completi sono visualizzati solo leggendo l'html direttamente o guardando ogni singolo test - Inizio di affermazioni sono difficili da vedere nel codice html - Fornire un modo visivo per visualizzare l'affermazione è facilmente il problema che stiamo cercando di risolvere.
Il punto principale è quello di colorare le affermazioni (testo specifica se stessa) utilizzando i tag HTML. La ricerca è stata fatto che i tag HTML da utilizzare. Div, span, tavolo e tag font sono guardato. La soluzione migliore è il tag font. Quindi il testo è circondato con tag font. L'attributo class del tag font corrisponde al tipo di affermazione. Fe se il asserion è nuovo è colorato di rosso, per indicare, che i test devono essere scritti, affermazioni vecchi sono colorati di verde per indicare che i test già esistenti. Ci dovrebbe essere una utility (uno script o un programma Java) per eseguire la scansione marcato capitolato d'oneri e aggiunge automaticamente i tag necessari per la colorazione. Il colore di sfondo del testo sarà determinato dal colore del titolo attributo della affermazione. Questo metodo è stato applicato e funziona bene. Ai fini dell'usabilità, ci dovrebbe essere un meccanismo per nascondere la colorazione, la fe un javascript.
Uno svantaggio di questa soluzione è che il colore è statica in quanto essa si basa su l'attributo title. Una seconda soluzione potrebbe essere che lo strumento sarebbe di controllo per una esistenza di un test (in base all'ID affermazione o il link nella affermazione). Se esiste un test, dovremmo fare qualcosa per impostare il colore di questa affermazione. Potrebbe essere semplice come la fissazione di un attributo title. Uno svantaggio di questa soluzione sarebbe che la colorazione affermazione sarebbe ancora statico, ma in base a quando l'utente esegue gli script.
Una variante della soluzione data è che avremmo generare dinamicamente i dati di copertura quando la specifica è visualizzato in un browser. Vogliamo determinare se un test presente nella directory di prova per una determinata affermazione e il colore l'affermazione di conseguenza. Ciò potrebbe essere fatto attraverso un JavaScript / VBScript utilizzando oggetti, che permettono l'accesso del file system. Questo metodo dovrebbe essere dinamico e deve avere sempre le ultime status copertura affermazione.
Ecco alcuni esempi da JLS3 capitoli "Conversioni e Promozioni" e "interfacce":
Asserzioni conv063, conv047, conv065, conv48, conv66 e conv049 sono dalla versione precedente di specifiche, essi non sono stati modificati e aggiornare le prove non è necessario - il colore è acquamarina (verde neurtal). Conv155 e conv156 sono nuovi, nuovi test dovrebbero essere sviluppate, le affermazioni sono colorati in rosso abbagliante. Conv064 è stato modificato, l'aggiornamento di prova è necessario - colore arancio. Annot019 è nuova, le prove esistono, ma sono necessari per cambiare - di colore salmone. Annot020 è nuovo, ma esistono prove кудумфте - colore verde chiaro.
Il vantaggio principale di colorazione specifica è che la specifica è visualizzato. L'utente può vedere l'intero affermazione e il suo titolo. Si può dire guardando le specifiche, dove ci sono zone con bassa copertura, dove alcune o molte prove devono essere aggiunti o modificati. Non vi è praticamente la possibilità di vedere quanto bene una specifica è marcato e quanto bene è testato.
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 ', fare, 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 è testabile, 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. 
