aent: online nel cloud

PROGRAMMA:

NOME

aegis new test: aggiunge un nuovo test a una modifica

SINOSSI

egida -Nuovo_Test [ opzione... ][ Nome del file...]
egida -Nuovo_Test -Elenco [ opzione...]
egida -Nuovo_Test -Aiuto

DESCRIZIONE

I traghetti di egida -Nuovo_Test Il comando viene utilizzato per aggiungere un nuovo test a una modifica. Viene creato un nuovo file
nella directory di sviluppo.

I nuovi test vengono impostati automaticamente su "automatico" se non diversamente specificato.

Compila il Nome Interpretazione
Il programma aegis tenterà di determinare i nomi dei file di progetto dai nomi dei file
dato sulla riga di comando. Tutti i nomi dei file sono memorizzati all'interno dei progetti aegis come relativi
alla radice dell'albero di directory di base. La directory di sviluppo e il
directory di integrazione sono ombre di questa directory di base, e quindi questi nomi relativi
applica anche qui. I file nominati sulla riga di comando vengono prima convertiti in percorsi assoluti
se necessario. Vengono quindi confrontati con il percorso di base, la directory di sviluppo
percorso e il percorso della directory di integrazione per determinare un nome relativo alla linea di base. è
un errore se il file denominato è al di fuori di uno di questi alberi di directory.

I traghetti di -BASE_RElativo l'opzione può essere usata per far interpretare i nomi di file relativi come
rispetto al percorso della linea di base; i nomi di file assoluti verranno comunque confrontati con i vari
percorsi per determinare un nome relativo alla linea di base.

I traghetti di relativo_nome_file_preferenza nel file di configurazione utente può essere utilizzato per modificare
questo comportamento predefinito. Vedere aeuconf(5) per maggiori informazioni.

Test Nome del file Generazione
Puoi scegliere il tuo nome file per un test, specificandolo sulla riga di comando.

Se sulla riga di comando non viene specificato alcun nome file, viene automaticamente inserito un nome file di prova
generato. Questo è controllato da nuovo_nomefile_prova campo del progetto
file di configurazione (vedi aepconf(5) per ulteriori informazioni. Tutto generato automaticamente
i nomi dei file di test all'interno di un progetto sono numerati in modo univoco. Il modello predefinito per il nuovo test
i nomi dei file sono "prova/XX/tXXXX[am].sh", dove XX sono le prime 2 cifre del numero del test,
XXXX è l'intero numero del test e [sono] è a per i test automatici e m per i test manuali.

Modifica Test
I test potranno essere modificati in futuro aggiungendoli ad una modifica con il file PCEA(1) comando.
I test vengono trattati come qualsiasi altro file sorgente e sono soggetti allo stesso processo.

Compila il Modelli
Quando viene creato un nuovo file nella directory di sviluppo, il progetto config il file è
cercato un modello per il nuovo file. Se viene trovato un modello, il nuovo file sarà
inizializzato al modello, altrimenti verrà creato vuoto. Vedere aepconf(5) per di più
informazioni.

La forma più semplice è utilizzare file modello, come
file_modello =
[
{
modello = [ "*.c" ];
body = "${read_file ${source template/c abs}}";
},
{
modello = ["prova/*/.sh"];
body = "${read_file ${modello di origine/test abs}}";
},
];
Come puoi vedere, i file modello fanno parte dell'origine del progetto, quindi puoi aggiungere il file
avvisi di copyright e wrapper appropriati, eccetera. $fonte la sostituzione li localizza,
se non fanno parte del cambiamento in corso (e di solito non lo sono).

I file modello stessi contengono sostituzioni. IL $nomefile la sostituzione è
disponibile e contiene il nome del file in fase di creazione. Questo può essere manipolato
vari modi durante la costruzione del contenuto del file appropriato. Vedere esub(5) per di più
informazioni sulle sostituzioni.

È anche possibile eseguire un comando per creare il nuovo file. Puoi farlo invece di
specificando una stringa del corpo, cioè:
file_modello =
[
{
modello = [ "*" ];
body_command = "perl ${source template.pl abs} $nomefile";
},
];
Il comando viene eseguito con la directory corrente impostata all'inizio della directory di sviluppo.
È un errore se il comando non riesce a creare il file. Puoi mescolare e abbinare i due
tecniche, stile di vita corda e comando_corpo, se vuoi.

Fare attenzione ad assicurarsi che il modello del modello del nome del file di prova corrisponda al file
nuovo_nomefile_prova campo.

Compila il Nome Limiti
Sono disponibili numerosi controlli per limitare la forma dei nomi dei file di progetto. Tutto di
questi controlli possono essere trovati nel file di configurazione del progetto, vedere aepconf(5) per di più
informazione. I più significativi vengono qui brevemente descritti:

lunghezza_nome_file_massima = intero;
Questo campo viene utilizzato per limitare la lunghezza dei nomi di file. Tutti i nuovi file potrebbero non avere
componenti del percorso più lunghi di questo. Il valore predefinito è 255 se non impostato. Per il massimo
portabilità dovresti impostarlo su 14.

posix_filename_charset = booleano;
Questo campo può essere utilizzato per limitare i caratteri consentiti nei nomi dei file solo a quelli
esplicitamente consentito da POSIX. Il valore predefinito è falso se non impostato, significa qualunque sia il tuo
il sistema operativo tollererà, ad eccezione degli spazi bianchi e dei caratteri ad alto bit-on.
Per la massima portabilità dovresti impostarlo su vero.

dos_filename_required = booleano;
Questo campo può essere utilizzato per limitare i nomi dei file in modo che siano conformi al DOS 8+3
limiti dei nomi file e al set di caratteri dei nomi file DOS. Il valore predefinito è falso altrimenti
impostato.

windows_filename_required = booleano;
Questo campo può essere utilizzato per limitare i nomi dei file in modo che siano conformi a Windows98
e limiti dei nomi file e set di caratteri di Windows NT. Il valore predefinito è falso se non impostato.

shell_safe_filenames = booleano;
Questo campo può essere utilizzato per limitare i nomi dei file in modo che non contengano shell
personaggi speciali. Il valore predefinito è vero se non impostato. Se questo campo è impostato su falso,
dovrai usare il ${quote} sostituzione attorno ai nomi dei file nei comandi, a
assicurarsi che i nomi dei file contenenti caratteri speciali della shell non abbiano caratteri indesiderati
effetti collaterali. Anche i caratteri strani nei nomi dei file possono confondere la tua dipendenza
strumento di manutenzione.

consent_white_space_in_filenames = booleano;
Questo campo può essere utilizzato per consentire caratteri di spazio bianco nei nomi dei file. Questo sarà
consentire la visualizzazione dei seguenti caratteri nei nomi dei file: backspace (BS, \b, 0x08),
tabulazione orizzontale (HT, \t, 0x09), nuova riga (NL, \n, 0x0A), tabulazione verticale (VT, \v,
0x0B), avanzamento modulo (FF, \f, 0x0C) e ritorno a capo (CR, \r, 0x0D). Il valore predefinito è
false se non impostato.

Tieni presente che questo campo non sovrascrive altri filtri dei nomi di file. Sarà
necessario impostare esplicitamente nomifile_shell_safe = falso anche. Sarà
necessario impostare dos_nomefile_richiesto = falso (l'impostazione predefinita). Sarà
necessario impostare posix_filename_charset = falso (l'impostazione predefinita).

L'utente deve fare molta attenzione a utilizzare la sostituzione ${quote} attorno a tutti i file
nomi nei comandi nella configurazione del progetto. E anche allora, sostituzioni
che prevedono un elenco di nomi di file separati da spazi avranno risultati non definiti.

consentire_non_ascii_filenames = booleano;
Questo campo può essere utilizzato per consentire nomi di file con caratteri non stampabili ASCII
loro. Di solito questo significherebbe un UTF8 o un set di caratteri internazionale di qualche tipo.
Il valore predefinito è false se non impostato.

Tieni presente che questo campo non sovrascrive altri filtri dei nomi di file. Sarà
necessario impostare esplicitamente nomifile_shell_safe = falso anche. Sarà
necessario impostare dos_nomefile_richiesto = falso (l'impostazione predefinita). Sarà
necessario impostare posix_filename_charset = falso (l'impostazione predefinita).

nomefile_modello_accetta = [stringa];
Questo campo viene utilizzato per specificare un elenco di modelli di nomi di file accettabili.
Il valore predefinito è "*" se non impostato.

nomefile_modello_rifiuta = [stringa];
Questo campo viene utilizzato per specificare un elenco di modelli di nomi di file non accettabili.

Per favore, Nota: Aegis consulta anche il file system sottostante, per determinare la sua nozione di
dimensione massima del file. Dove la dimensione massima del file del file system è inferiore a
lunghezza_massima_nome_file, vince il filesystem. Questo può succedere, ad esempio, quando sei
usando il file system Linux UMSDOS, o quando hai un NFS montato un vecchio V7
file system. Collocamento lunghezza_massima_nome_file a 255 in questi casi non altera il
fatto che i limiti dei file system sottostanti sono molto più piccoli (rispettivamente 12 e 14).

Se le tue directory di sviluppo (o l'intero progetto) sono su filesystem con nome file
limitazioni, o una parte delle costruzioni eterogenee ha luogo in un tale ambiente,
aiuta a dire ad Aegis cosa sono (usando il progetto config campi del file) in modo che tu
non incorrere nella situazione in cui il progetto si basa sul più permissivo
ambienti, ma fallisce con misteriosi errori negli ambienti più limitati.

Se le tue directory di sviluppo si trovano regolarmente su un filesystem Linux UMSDOS, dovresti
probabilmente sarebbe meglio impostare dos_nomefile_richiesto = vero, e anche cambiando il
sviluppo_directory_template campo. Sviluppo eterogeneo con varie finestre
anche gli ambienti possono richiederlo.

Cambiare , il Tipologia of a Compila il
Se vuoi cambiare il tipo di un file (diciamo, da un file di prova a un file sorgente, o vice
versa) potresti farlo come due modifiche, usando prima aerma(1) in un cambio e poi
utilizzando aenf(1) o aent(1) in una seconda modifica, oppure puoi combinare entrambi i passaggi nello stesso
modificare. Ricordati di usare il aerma -nessun bianco opzione o otterrai una novità molto particolare
modello di file.

Notifica
I traghetti di nuovo_comando_test nel progetto config file viene eseguito, se impostato. Il comando_file_progetto
viene eseguito anche, se impostato, e se c'è stata un'integrazione di recente. Vedere aepconf(5) per
maggiori informazioni.

TEST PROCESSO

Ogni modifica deve essere accompagnata da test e tali test devono essere
eseguire contro la directory di sviluppo compilata e devono passare. Questo assicura che il nuovo
la funzionalità è accompagnata da test per verificarne la correttezza e le correzioni di bug sono
accompagnato da test che confermano che il bug è stato corretto.

Regressione Test
I test vengono trattati come qualsiasi altro file sorgente e vengono mantenuti nella linea di base e
cronologia con tutti gli altri file di origine. I test che devono accompagnare ogni cambiamento
accumularsi nella linea di base del progetto, fornendo una definizione della corretta funzione per il
linea di base. Questi test accumulati possono essere eseguiti utilizzando un comando "aegis -REGression",
per verificare che il progetto non “regredirà” a seguito di una modifica.

Linea di base Test
Le correzioni di bug sono necessarie per avere i loro test fallire rispetto alla linea di base del progetto (al contrario
alla directory di sviluppo). Ciò garantisce che il test dimostri effettivamente il bug
nella linea di base, oltre a dimostrare che è fissato dal cambiamento. Nuovo
la funzionalità fallisce banalmente rispetto alla linea di base, quindi aegis non tenta di farlo
indovina se un test è un test di correzione di bug o un test di nuove funzionalità, richiede semplicemente dei test per
fallire contro la linea di base.

Questo requisito si applica sia ai nuovi test creati da una modifica, sia ai test
che sono stati copiati in una modifica per la modifica.

Revisione Test
I revisori possono essere certi che aegis abbia applicato i requisiti del test; che un cambiamento
deve avere test, che il cambiamento deve costruire, che i test passino contro lo sviluppo
directory e che i test abbiano esito negativo rispetto alla linea di base. Queste condizioni sono applicate
by aede(1) e la modifica non verrà anticipata al essendo rivisto stato fino a questi
le condizioni sono soddisfatte. I revisori dovrebbero quindi rivedere i test per completezza di copertura di
il codice nella modifica e l'insensibilità alle modifiche nell'ambiente di esecuzione (ad es
non sensibile alla data). I revisori dovrebbero anche usare "aegis -list change_details" per verificare
che una modifica ha o non ha esenzioni dai test.

esenzioni
Varie esenzioni dai test possono essere concesse dagli amministratori del progetto, vedere aep(1) e
aepattr(5) per maggiori informazioni. Copiare i test in una modifica o aggiungere nuovi test a a
modifica, può annullare tali esenzioni.

TEST CORRELAZIONI

Il comando "aegis -Test -SUGgest" può essere usato per fare in modo che aegis suggerisca una regressione adeguata
verifica la tua modifica, in base ai file di origine nella tua modifica. Questo automaticamente
concentra lo sforzo di test sui test pertinenti, riducendo il numero di test di regressione
necessario essere sicuri di non aver introdotto un bug.

Le correlazioni di test sono generate dal comando “aegis -Integrate_Pass”, che
associa ogni test nella modifica a ogni file sorgente nella modifica. Così, ogni
file sorgente accumula un elenco di test che sono stati associati in passato.
Questo non è esatto come l'analisi della copertura del codice, ma è un'approssimazione ragionevole in
pratica.

I traghetti di PCEA(1) e aenf(1) i comandi vengono utilizzati per associare i file a una modifica. Mentre loro
non eseguire attivamente l'associazione, questi sono i file utilizzati da aeipass(1) e
e(1) per determinare quali file di origine sono associati a quali test.

Test Correlazione Precisione
Supponendo che le correlazioni dei test siano accurate e che i test siano uniformi
distribuito nello spazio delle funzioni, ci sarà meno di 1/numero possibilità che a
relativo test non è stato eseguito da “aegis -Test -SUGgest numerocomando. Un piccolo
la quantità di rumore viene aggiunta alla ponderazione del test, in modo che a volte si verifichino cose inaspettate
testato e gli stessi test non vengono eseguiti ogni volta.

L'accuratezza della correlazione del test può essere migliorata assicurando che:

· Ogni modifica dovrebbe essere fortemente focalizzata, senza inclusioni di file gratuite. Questo
evita correlazioni spurie.

· Ogni elemento di nuova funzionalità dovrebbe essere aggiunto in un singolo cambiamento, piuttosto che
diversi insieme. Questo correla fortemente i test con la funzionalità.

· Ogni bug dovrebbe essere corretto in un singolo cambiamento, piuttosto che diversi insieme. Questo
correla fortemente i test con la funzionalità.

· Le correlazioni di prova andranno perse se i file vengono spostati. Questo perché le correlazioni sono di
nome.

Il modo migliore per correlare accuratamente i test con i file di origine è quando un cambiamento
contiene un test ed esattamente quei file relativi alla funzionalità in prova. Pure
molti file spuri indeboliranno l'utilità delle correlazioni di test.

VERSIONI

Sono comprese le seguenti opzioni;

-Automatico
Questa opzione può essere utilizzata per specificare i test automatici. I test automatici non richiedono
assistenza umana.

-BASE_RElativo
Questa opzione può essere usata per far sì che i nomi di file relativi siano considerati relativi a
la base dell'albero di origine. Vedere aeuconf(5) per l'utente corrispondente
preferenza.

-COrrent_RElativo
Questa opzione può essere usata per far sì che i nomi di file relativi siano considerati relativi a
la directory corrente. Di solito è l'impostazione predefinita. Vedere aeuconf(5) per la
corrispondente preferenza dell'utente.

-Modificare numero
Questa opzione può essere utilizzata per specificare una particolare modifica all'interno di un progetto. Vedere
egida(1) per una descrizione completa di questa opzione.

-Aiuto
Questa opzione può essere utilizzata per ottenere maggiori informazioni su come utilizzare il egida
.

-Elenco
Questa opzione può essere utilizzata per ottenere un elenco di soggetti idonei per questo comando.
L'elenco potrebbe essere più generale del previsto.

-Manuale Questa opzione può essere utilizzata per specificare i test manuali. I test manuali richiedono un po' di persone
intervento, es: conferma di alcuni comportamenti dello schermo (X11, per esempio), oppure
qualche azione dell'utente, "scollegare il cavo ethernet ora".

-Non_registrazione
Questa opzione può essere utilizzata per disabilitare la registrazione automatica dell'output e degli errori per
un file. Questo è spesso utile quando diversi comandi di aegis sono combinati in una shell
script.

-Produzione Nome del file
Questa opzione può essere usata per specificare un nome di file che deve essere scritto con il
nome del file di test determinato automaticamente. Utile per scrivere script.

-Progetto Nome
Questa opzione può essere utilizzata per selezionare il progetto di interesse. quando no -Progetto
l'opzione è specificata, il AEGIS_PROGETTO viene consultata la variabile di ambiente. Se
che non esiste, l'utente $HOME/.aegisrc il file viene esaminato per un valore predefinito
campo del progetto (vedi aeuconf(5) per maggiori informazioni). Se ciò non esiste,
quando l'utente sta lavorando solo sulle modifiche all'interno di un singolo progetto, il progetto
nome predefinito su quel progetto. Altrimenti è un errore.

-Modello
Questa opzione può essere utilizzata anche per specificare che deve essere utilizzato un nuovo modello di file
se il file esiste già.

-No_TEMPlate
Questa opzione può essere utilizzata per specificare che non deve essere utilizzato un nuovo modello di file,
anche se il file non esiste (verrà creato l'eventuale file vuoto).

-TERse
Questa opzione può essere utilizzata per far sì che le inserzioni producano il minimo indispensabile di
informazione. Di solito è utile per gli script di shell.

-Verboso
Questa opzione può essere utilizzata per far sì che aegis produca più output. Per impostazione predefinita egida
produce solo output sugli errori. Se utilizzato con il -Elenco opzione questa opzione
causa l'aggiunta di intestazioni di colonna.

-Aspettare Questa opzione può essere utilizzata per richiedere ai comandi Aegis di attendere i blocchi di accesso, se
non possono essere ottenuti immediatamente. Impostazioni predefinite per l'utente lock_wait_preference
se non specificato, vedi aeuconf(5) per maggiori informazioni.

-Non aspettare
Questa opzione può essere utilizzata per richiedere ai comandi Aegis di emettere un errore fatale se access
i blocchi non possono essere ottenuti immediatamente. Impostazioni predefinite per l'utente
lock_wait_preference se non specificato, vedi aeuconf(5) per maggiori informazioni.

Vedi anche egida(1) per le opzioni comuni a tutti i comandi aegis.

Tutte le opzioni possono essere abbreviate; l'abbreviazione è documentata come le lettere maiuscole,
tutte le lettere minuscole ei caratteri di sottolineatura (_) sono facoltativi. Devi usare consecutivo
sequenze di lettere facoltative.

Tutte le opzioni non fanno distinzione tra maiuscole e minuscole, puoi digitarle in maiuscolo o minuscolo o a
combinazione di entrambi, il caso non è importante.

Ad esempio: gli argomenti "-project, "-PROJ" e "-p" sono tutti interpretati come il
-Progetto opzione. L'argomento "-prj" non sarà compreso, perché consecutivo
caratteri facoltativi non sono stati forniti.

Opzioni e altri argomenti della riga di comando possono essere mescolati arbitrariamente sulla riga di comando,
dopo i selettori di funzione.

I nomi lunghi delle opzioni GNU sono compresi. Poiché tutti i nomi delle opzioni per egida sono lunghi,
questo significa ignorare l'extra '-'. Il "--opzione=APPREZZIAMO"convenzione è anche
inteso.

CONSIGLIATO ALIAS

L'alias consigliato per questo comando è
csh% alias aent 'aegis -nt \!* -v'
sh$ aent(){aegis -nt "$@" -v}

ERRORI

È un errore se la modifica non è nel essendo sviluppato stato.
È un errore se la modifica non è assegnata all'utente corrente.

EXIT STATUS

I traghetti di egida il comando uscirà con uno stato di 1 su qualsiasi errore. Il egida il comando sarà solo
esci con stato 0 se non ci sono errori.

AMBIENTE VARIABILI

See egida(1) per un elenco di variabili d'ambiente che possono influenzare questo comando. Vedere
aepconf(5) per i file di configurazione del progetto specifico del progetto campo per come impostare
variabili d'ambiente per tutti i comandi eseguiti da Aegis.

Utilizza l'agente online utilizzando i servizi onworks.net