Assertion.ru

L'intero processo di creazione di un codice e lo sviluppo di test molto tempo. E quando sembra che il lavoro è fatto, una nuova versione della specifica viene rilasciato. Cosa succede dopo? Naturalmente vi è la necessità di una nuova versione della suite di test. Nuovi test deve essere scritta e quelle vecchie aggiornati o addirittura eliminato.

Il modo migliore per iniziare è fare la marcatura. Questo compito può essere suddiviso in due attività:

• trasferimento dal vecchio codice spec precedente alla nuova specifica (questo è necessario perché molte prove sono già state scritte, esse sono legati a specifiche id, il riutilizzo di tutti i test possibili è una buona idea);
• markup affermazioni nuovi e aggiornati.

Trasferire il codice è abbastanza semplice per farlo a mano:

1. Trovare il tag di marcatura nelle specifiche del vecchio.
2. Trovare il posto migliore per inserire il tag nella nuova versione di spec.
3. Inserire il tag.

Se ci sono solo 10 affermazioni - questo lavoro è un pezzo di torta. Ma se ce ne sono migliaia, è un lavoro duro che dovrebbe essere automatizzati. La parte più difficile è trovare una nuova sede adeguata per i tag di marcatura. E 'difficile solo perché la specifica è stata modificata. Per JLS2 per il processo di migrazione JLS3 alrorithm flollowing è stato utilizzato:

Ogni affermazione è arrotondata con ancore html. Entrambi dovrebbero essere trasferiti utilizzando l'algoritmo del genere.

Adottare algoritmo potrebbe essere utilizzato sia con ignorando tag html e di trarne vantaggio. Algoritmo è valido per le specifiche scritte in formato testo, HTML o XML.

Questo algoritmo è stato implementato in JLS2-> strumento JLS3 trasferimento markup. L'84% dei marcatori sono stati trasferiti automaticamente. Il resto di loro sono state effettuate manualmente.

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:

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:

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.

Oggi è un grande giorno. Cercherò di spiegare perché. Come ho detto nel mio intro-post la nostra squadra è la creazione di diversi TCK differente. L'area che ci lavoro è LANG cosiddetto - I test per sviluppare linguaggio Java. Molto tempo fa, più di 2 anni da oggi, abbiamo iniziato a lavorare su JLS 3 specificazione . Abbiamo dovuto risolvere molti problemi che spesso si verificano durante il cambio spec (mi prometto di scrivere più su questo). Il nostro team sta finendo JCK 6a, lang test fa parte di questo JCK. Oggi ho eseguito gli script di copertura e finalmente possiamo dire che abbiamo una copertura 99% per l'affermazione JLS 3. Per essere più precisi, abbiamo 99,4%. Significa che abbiamo scritto test per il 99% di sentances in JLS 3 che avevamo segnato come potenzialmente verificabili. Non è cool? Scommetto che è!

Il lavoro non è certo ancora finita e non sarà così - ci sono molte ragioni per cui sono necessari più test:

• miglioramento approfondimenti - Prove di più per diverse affermazioni sono necessarie;
• ci sono sentances che sono verificabili, ma per vari motivi non li aveva contrassegnato come potenzialmente verificabili;
• ci saranno 4 JLS presto, dovremmo cominciare a lavorare su di esso il più presto possibile.

Persone diverse potrebbero avere risposte di fronte ad una questione che in un titolo. La maggior parte direbbe: "Sì, naturalmente". Infatti il 99% è quasi il 100%. E ciò che è al 100% - si tratta di una perfezione. Il 99% sembra grande, ed è grande. Ma dobbiamo capire che cosa questo numero rappresenta, e cosa può essere migliorato. La mia opinione è "sì, è grande, colossale, enorme, ma no, non basta, voglio di più, anche oltre il 100%", è per questo che ho intenzione di creare uno script per il calcolo approfondimenti.