InglêsFrancêsEspanhol

Executar servidores | Ubuntu > | Fedora > |


favicon do OnWorks

lit-3.8 - Online na nuvem

Execute lit-3.8 no provedor de hospedagem gratuita OnWorks no Ubuntu Online, Fedora Online, emulador online do Windows ou emulador online do MAC OS

Este é o comando lit-3.8 que pode ser executado no provedor de hospedagem gratuita OnWorks usando uma de nossas várias estações de trabalho online gratuitas, como Ubuntu Online, Fedora Online, emulador online do Windows ou emulador online do MAC OS

PROGRAMA:

NOME


aceso - testador integrado LLVM

SINOPSE


cama [opções] [testes]

DESCRIÇÃO


cama é uma ferramenta portátil para executar suítes de teste estilo LLVM e Clang, resumindo seus
resultados, e fornecendo indicação de falhas. cama é projetado para ser leve
ferramenta de teste com uma interface de usuário o mais simples possível.

cama deve ser executado com um ou mais testes para executar especificado na linha de comando. Os testes podem
ser arquivos de teste individuais ou diretórios para pesquisar os testes (ver TESTE DESCUBRA).

Cada teste especificado será executado (potencialmente em paralelo) e uma vez que todos os testes
foi executado cama irá imprimir informações resumidas sobre o número de testes que passaram ou falharam
(Vejo TESTE STATUS PREÇO/ RESULTADOS). O cama o programa será executado com um código de saída diferente de zero, se houver
os testes falham.

Por padrão cama usará uma exibição de progresso sucinta e imprimirá apenas o resumo
informações para falhas de teste. Ver SAÍDA OPÇÕES para opções que controlam o cama
exibição de progresso e saída.

cama também inclui uma série de opções para controlar como os testes são executados (específico
recursos podem depender do formato de teste específico). Ver EXECUÇÃO OPÇÕES para mais
informações.

Finalmente, cama também suporta opções adicionais para executar apenas um subconjunto das opções
especificado na linha de comando, consulte SELEÇÃO OPÇÕES Para obter mais informações.

Usuários interessados ​​no cama arquitetura ou projetando um cama implementação de teste deve
Vejo ACESO A INFRAESTRUTURA.

SUPORTE OPÇÕES


-h, --Socorro
Mostra a cama mensagem de ajuda.

-j N, --threads = N
Corrida N testes em paralelo. Por padrão, isso é automaticamente escolhido para corresponder ao
número de CPUs disponíveis detectadas.

--config-prefix = NAME
Procurar por NOME.cfg e NOME.site.cfg quando pesquisar por teste suítes, em vez disso of
lit.cfg e lit.site.cfg.

-D NAME -D NOME = VALOR, --param NAME --param NAME = VALUE
Adicionar um parâmetro definido pelo usuário NOME com o dado VALOR (ou a string vazia se não
dado). O significado e o uso desses parâmetros dependem do conjunto de testes.

SAÍDA OPÇÕES


-q, --quieto
Suprima qualquer saída, exceto para falhas de teste.

-sim, --sucinto
Mostra menos saída, por exemplo, não mostra informações sobre os testes que passam.

-v, --verbose
Mostra mais informações sobre as falhas do teste, por exemplo, toda a saída do teste
de apenas o resultado do teste.

-uma, --mostre tudo
Mostra mais informações sobre todos os testes, por exemplo, toda a linha de comando do teste e
saída.

--no-progress-bar
Não use a barra de progresso baseada em curses.

--show-unsupported
Mostra os nomes dos testes não suportados.

--show-xfail
Mostre os nomes dos testes que deveriam falhar.

EXECUÇÃO OPÇÕES


--path = PATH
Especifique um adicional PATH para usar ao pesquisar executáveis ​​em testes.

--vg Execute testes individuais em valgrind (usando a ferramenta memcheck). o
- código de saída de erro argumento para valgrind é usado para que as falhas de valgrind causem
o programa saia com um status diferente de zero.

Quando esta opção está habilitada, cama também fornecerá automaticamente um "Valgrind"
recurso que pode ser usado para desabilitar condicionalmente (ou esperar falha em) certos
testes.

--vg-arg = ARG
Quando --vg é usado, especifique um argumento adicional para passar para Valgrind si.

--vg-vazamento
Quando --vg for usado, habilite verificações de vazamento de memória. Quando esta opção está habilitada, cama
também fornecerá automaticamente um "vg_leak"recurso que pode ser usado para
desative condicionalmente (ou espere falha em) certos testes.

--testes de tempo
Rastreie o tempo que os testes individuais levam para executar e inclui os resultados em
o resultado do resumo. Isso é útil para determinar quais testes em um conjunto de testes
leva mais tempo para executar. Observe que esta opção é mais útil com -j 1.

SELEÇÃO OPÇÕES


--max-tests = N
Correr no máximo N testes e, em seguida, encerrar.

--max-time = N
Gastar no máximo N segundos (aproximadamente) executando testes e, em seguida, encerrar.

- shuffle
Execute os testes em uma ordem aleatória.

ADICIONAL OPÇÕES


--depurar
Corrida cama no modo de depuração, para depurar problemas de configuração e cama si.

--show-suites
Liste os conjuntos de testes descobertos e saia.

--show-tests
Liste todos os testes descobertos e saia.

SAIR STATUS


cama sairá com um código de saída 1 se houver resultados de FALHA ou XPASS. De outra forma,
ele sairá com o status 0. Outros códigos de saída são usados ​​para falhas não relacionadas ao teste
(por exemplo, um erro do usuário ou um erro interno do programa).

TESTE DESCUBRA


As entradas foram passadas para cama podem ser testes individuais ou diretórios inteiros ou
hierarquias de testes a serem executados. Quando cama inicia, a primeira coisa que faz é converter o
entradas em uma lista completa de testes a serem executados como parte de teste descoberta.

Na série cama modelo, cada teste deve existir dentro de algum teste suíte. cama resolve as entradas
especificado na linha de comando para suítes de teste pesquisando para cima a partir do caminho de entrada
até encontrar um lit.cfg or lit.site.cfg Arquivo. Esses arquivos servem como um marcador de teste
suites e como arquivos de configuração que cama carrega para entender como encontrar e
execute os testes dentro do conjunto de testes.

Uma vez cama mapeou as entradas em suítes de teste, percorre a lista de entradas adicionando
testa arquivos individuais e busca recursivamente por testes em diretórios.

Este comportamento torna mais fácil especificar um subconjunto de testes a serem executados, ao mesmo tempo que permite o
configuração do conjunto de testes para controlar exatamente como os testes são interpretados. Além disso, cama
sempre identifica os testes pelo conjunto de testes em que estão e seu caminho relativo dentro do
suíte de teste. Para projetos configurados apropriadamente, isso permite cama para fornecer conveniente
e suporte flexível para compilações fora da árvore.

TESTE STATUS PREÇO/ RESULTADOS


Cada teste produz, em última análise, um dos seguintes seis resultados:

PASSAR
O teste foi bem-sucedido.

XFAIL
O teste falhou, mas isso é esperado. Isso é usado para formatos de teste que permitem
especificando que um teste não funciona atualmente, mas deseja deixá-lo no conjunto de testes.

XPASS
O teste foi bem-sucedido, mas esperava-se que ele falhasse. Isso é usado para testes que foram
especificado como esperado para falhar, mas agora está tendo sucesso (geralmente porque o recurso
o teste foi quebrado e foi corrigido).

FALHA
O teste falhou.

NÃO RESOLVIDO
O resultado do teste não pôde ser determinado. Por exemplo, isso ocorre quando o teste poderia
não foi executado, o teste em si é inválido ou o teste foi interrompido.

NÃO SUPORTADO
O teste não é compatível com este ambiente. Isso é usado por formatos de teste que podem
relatar testes não suportados.

Dependendo do formato do teste, os testes podem produzir informações adicionais sobre seu status
(geralmente apenas para falhas). Veja o SAÍDA OPÇÕES seção para mais informações.

ACESO A INFRAESTRUTURA


Esta seção descreve o cama arquitetura de teste para usuários interessados ​​em criar um novo
cama testar a implementação ou estender uma existente.

cama adequada é principalmente uma infraestrutura para descobrir e executar testes arbitrários, e
para expor uma única interface conveniente para esses testes. cama em si não sabe como correr
testes, em vez disso, essa lógica é definida por teste suites.

TESTE SUITES
Conforme descrito em TESTE DESCUBRA, os testes estão sempre localizados dentro de um teste suíte. Suítes de teste
servem para definir o formato dos testes que eles contêm, a lógica para encontrar esses testes,
e qualquer informação adicional para executar os testes.

cama identifica suítes de teste como diretórios contendo lit.cfg or lit.site.cfg arquivos (ver
tb --config-prefix) As suítes de teste são inicialmente descobertas pesquisando recursivamente
a hierarquia de diretório para todos os arquivos de entrada passados ​​na linha de comando. Você pode usar
--show-suites para exibir os conjuntos de testes descobertos na inicialização.

Depois que um conjunto de testes é descoberto, seu arquivo de configuração é carregado. Os próprios arquivos de configuração são
Módulos Python que serão executados. Quando o arquivo de configuração é executado, dois importantes
variáveis ​​globais são predefinidas:

lit_config
O mundial cama objeto de configuração (um LitConfig instância), que define o
formatos de teste, parâmetros de configuração global e outras rotinas auxiliares para
implementação de configurações de teste.

configuração
Este é o objeto de configuração (um TestingConfig instância) para o conjunto de testes, que o
espera-se que o arquivo de configuração seja preenchido. As seguintes variáveis ​​também estão disponíveis no
configuração objeto, alguns dos quais devem ser definidos pela configuração e outros são opcionais ou
predefinido:

nome [obrigatório] O nome do conjunto de testes, para uso em relatórios e diagnósticos.

formato_teste [obrigatório] O objeto de formato de teste que será usado para descobrir e executar
testes no conjunto de testes. Geralmente, este será um formato de teste integrado disponível em
do lit.formatos módulo.

test_source_root O caminho do sistema de arquivos para a raiz do conjunto de testes. Para compilações fora do diretório
este é o diretório que será verificado em busca de testes.

test_exec_root Para compilações fora do diretório, o caminho para a raiz do conjunto de testes dentro do objeto
diretório. É aqui que os testes serão executados e os arquivos de saída temporários colocados.

meio Ambiente Um dicionário que representa o ambiente a ser usado ao executar testes em
a suíte.

sufixos Para se qualificar para o cama formatos de teste que fazem a varredura de diretórios em busca de testes, esta variável é uma lista
de sufixos para identificar arquivos de teste. Usado por: ShTestName.

substituições Para se qualificar para o cama formatos de teste que substituem variáveis ​​em um script de teste, o
lista de substituições a serem realizadas. Usado por: ShTestName.

não suportado Marque um diretório não suportado, todos os testes dentro dele serão relatados como
sem suporte. Usado por: ShTestName.

principal A configuração pai, este é o objeto de configuração para o diretório que contém
o conjunto de testes ou Nenhum.

raiz A configuração raiz. Este é o mais cama configuração no projeto.

falha na tubulação Normalmente, um teste usando um tubo de shell falha se algum dos comandos do tubo
falhou. Se isso não for desejado, definir esta variável como falsa fará com que o teste falhe apenas
se o último comando no tubo falhar.

TESTE DESCUBRA
Uma vez que as suítes de teste são localizadas, cama atravessa recursivamente o diretório de origem (seguindo
test_source_root) à procura de testes. Quando cama entra em um subdiretório, ele primeiro verifica se
veja se um conjunto de testes aninhado está definido nesse diretório. Em caso afirmativo, ele carrega esse conjunto de testes
recursivamente, caso contrário, ele instancia uma configuração de teste local para o diretório (ver LOCAL
CONFIGURAÇÃO ARQUIVOS).

Os testes são identificados pelo conjunto de testes em que estão contidos e pelo caminho relativo
dentro dessa suíte. Observe que o caminho relativo pode não se referir a um arquivo real no disco;
alguns formatos de teste (como GoogleTest) definem "testes virtuais" que têm um caminho que
contém o caminho para o arquivo de teste real e um subcaminho para identificar o teste virtual.

LOCAL CONFIGURAÇÃO ARQUIVOS
Quando cama carrega um subdiretório em um conjunto de testes, ele instancia uma configuração de teste local
clonando a configuração para o diretório pai --- a raiz desta configuração
cadeia sempre será um conjunto de testes. Assim que a configuração do teste for clonada cama verifica por um
lit.local.cfg arquivo no subdiretório. Se estiver presente, este arquivo será carregado e pode ser
usado para especializar a configuração de cada diretório individual. Esta facilidade pode ser
usado para definir subdiretórios de testes opcionais ou para alterar outra configuração
parâmetros --- por exemplo, para alterar o formato do teste ou os sufixos que identificam o teste
arquivos.

TESTE CORRE SAÍDA FORMATO
A cama a saída para uma execução de teste está em conformidade com o seguinte esquema, tanto em curto quanto em verboso
modos (embora no modo curto nenhuma linha PASS seja mostrada). Este esquema foi escolhido
para ser relativamente fácil de analisar de forma confiável por uma máquina (por exemplo, no buildbot log
raspagem) e para que outras ferramentas gerem.

Espera-se que cada resultado do teste apareça em uma linha que corresponda a:

: ( )

onde é um resultado de teste padrão, como PASSA, FALHA, XFAIL, XPASS,
NÃO RESOLVIDO ou NÃO SUPORTADO. Os códigos de resultado de desempenho de MELHORADO e REGRESSADO são
também permitido.

A <test nome> O campo pode consistir em uma string arbitrária sem nova linha.

A <progress info> campo pode ser usado para relatar informações de progresso, como (1/300) ou
pode estar vazio, mas mesmo quando vazio, os parênteses são obrigatórios.

Cada resultado de teste pode incluir informações de registro adicionais (multilinhas) no seguinte
formato:

TESTE '( ) '
... mensagem de log ...


onde <test nome> deve ser o nome de um teste relatado anteriormente, <log delineador> é uma
seqüência de caracteres "*" at mínimo quatro caracteres (o comprimento recomendado é 20), e
<trailing delineador> é uma string arbitrária (não analisada).

A seguir está um exemplo de uma saída de execução de teste que consiste em quatro testes A, B, C e
D e uma mensagem de log para o teste C reprovado:

PASSA: A (1 de 4)
APROVADO: B (2 de 4)
FALHA: C (3 de 4)
********************* FALHOU NO TESTE 'C' ********************
O teste 'C' falhou como resultado do código de saída 1.
********************
PASSA: D (4 de 4)

ACESO EXEMPLO TESTES
A cama distribuição contém vários exemplos de implementações de suítes de teste no
Testes de Exemplo diretório.

Use lit-3.8 online usando serviços onworks.net


Ad


Ad