Você pode fazer melhor dois diretórios paralelos, um para testes e outro
para arquivos de dados. Isso é o que eu fiz.
Am 04.03.2015 15:52 schrieb "Kyle P Davis" [email protected] :

Eu gostaria de poder fornecer um padrão de exclusão para que eu possa
apenas os arquivos de teste que correspondem ao meu padrão de arquivo de teste. Isso permitiria dados
arquivos coexistam com arquivos de teste, desde que sigam um razoável
padronizar.

Eu acho que isso seria simplesmente fornecer uma opção que define a opção de ignorar
em glob.

Pensamentos? Posso fazer uma RP bem rápido se você quiser.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/mochajs/mocha/issues/1577.

Eu poderia (e fiz no passado), mas prefiro não ter mais que fazer isso agora que percebi que glob ignore está bem ali.

Deve ser muito fácil adicionar um argumento de linha de comando para definir a opção glob ignore. Eu só queria ter ideias e discutir um pouco primeiro.

Alguma objeção à criação de um PR para isso?

Eu estava precisando disso também e fiquei surpresa ao ver que o mocha ainda não tinha. Acho que seria uma ótima adição. Temos um "testApp" dentro de nossa pasta de teste que usamos especificamente para teste. Não queremos o mocha tentando fazer testes dentro dessa pasta. Seria bom poder apenas adicionar uma exclusão ao nosso arquivo mocha.opts para excluir aquele caminho específico em vez de incluir explicitamente todas as outras subpastas de teste que temos.

Embora pudéssemos mover o testApp para fora, ele realmente não cabe em nenhum outro lugar do repositório e tem um caminho relativo para certos arquivos na pasta de teste.

Isso eu acho que seria uma boa adição. Certamente não é crítico, mas útil.

@KylePDavis @toddbluhm

Se eu precisasse disso, acho que provavelmente apenas

$ mocha $(find test/ ! -path '*testApp*')

Portanto, não estou muito entusiasmado com a ideia. Estou meio que em dúvida quanto à existência da bandeira recursive , já que a mesma coisa pode ser alcançada com um comando shell, Makefile , Gruntfile.js , gulpfile.js , etc., etc.

Acho que @boneskull tem um bom argumento - isso já é possível de várias maneiras. E isso sem incluir o fato de que você pode estruturar seus diretórios para evitar isso completamente. Por exemplo, dada esta estrutura:

$ tree .
.
└── spec
    ├── fixtures
    ├── integration
    └── unit

4 directories, 0 files

Você acabou de atualizar seu package.json para que possa simplesmente executar npm test

  "scripts": {
    "test": "mocha spec/unit spec/integration"
  }

Ou com uma estrutura como a seguinte:

$ tree .
.
└── src
    └── models
        ├── user.js
        └── userSpec.js

2 directories, 2 files

Você pode executar as especificações de maneira semelhante ao exemplo de @boneskull (isso só irá executar arquivos contendo Spec )

  "scripts": {
    "test": "mocha $(find src -name '*Spec.js')"
  }

Editar: corrigido :)

@danielstjules Eu acho que vai realmente atingir qualquer diretório com Spec no nome. Talvez você queira -name '*.spec.js'

Sim, você está certo! Peido de cérebro. Obrigado por apontar isso.

Comando fixo para o exemplo:

  "scripts": {
    "test": "mocha $(find src -name '*Spec.js')"
  }

Acho que ainda há um caso de uso válido para esse recurso: eu tendo a agrupar meus arquivos por recurso, de modo que cada arquivo de teste esteja próximo aos arquivos contendo a lógica que eles estão testando. Nomear arquivos de teste consistentemente funciona com o argumento file ou a opção grep mas eu gostaria de ignorar explicitamente coisas como node_modules .

Para quem procura - gulp-mocha pode conseguir isso, eu odeio incluir gulp onde não preciso.

Eu gostaria de reservar um momento e marcar esta ideia com +1. Ao contrário dos projetos JavaScript típicos, gosto de seguir a forma como o GO faz testes de unidade e incluo um arquivo de especificação ao lado de cada arquivo que é testado. Por exemplo, um diretório em um dos meus projetos pode se parecer com o seguinte:

main.js
main.spec.js
utilities.js
utilities.spec.js

Acho que esse tipo de organização torna muito mais fácil localizar o teste do que vasculhar um único diretório de arquivos de teste; você sempre espera que o teste fique bem próximo ao arquivo que ele testa e meu script de construção cria scripts de todos os arquivos .spec.js na versão implementada.

Devido ao meu layout não padrão, o que eu gostaria de poder fazer é executar todos os testes de unidade com todas as minhas pastas, exceto o diretório node_modules.

Não tenho uma caixa do Windows perto de mim no momento, mas não tenho certeza se essa sintaxe de localização funcionaria no Windows ou não; uma opção de exclusão seria muito mais intuitiva de qualquer maneira na minha opinião. Além disso, quase todas as estruturas de teste de unidade incluem uma maneira de ignorar arquivos de qualquer maneira, então a paridade seria bom.

Olá, todos os meus testes suportam o formato *.test.js . Eles estão todos no diretório tests . Atualmente, tenho alguns testes que desejo excluir e ainda manter o caminho padrão para mocha, que é ./test/**/*.js . Como faço isso?

Criar dois diretórios separados não funcionará aqui, e você deve concordar que mover os testes entre diretórios criaria muito ruído no VCS.

@calebthebrewer Felizmente estou usando gulp no projeto;) obrigado pela dica!

+1 @calebthebrewer

Angular 2.0 e Polymer me colocam no modo de componente, então concordo com @KrisSiegel. Manter todo o seu código em pacotes mantém uma hierarquia de arquivos limpa, modular e fácil de manter.

Existe algum problema previsível para carregar os testes usando a biblioteca q prometida de uma forma como esta:

import q from 'q';

import authRouterTest from '../app/routes/_authentication.router.e2e.js';

import productRouterTest from '../app/routes/_product.router.e2e.js';

import productModelTest from '../app/models/product.model.spec.js';

// Dynamically constructed sequence of functions
let funcs = [ productModelTest(), authRouterTest(), productRouterTest() ];

// This function takes an array of promise-producing functions and
// runs them sequentially.
let execTests = () => {

    let result = q();

    funcs.forEach((f) => {

        result = result.then(f);
    });

    return result;
};

// Execute tests
execTests();

Desta forma, você pode importar seus arquivos de qualquer lugar e ter apenas um arquivo de teste em test/ .

Você pode resolver a promessa no último bloco de teste e encerrar cada teste assim

import q from 'q'

export default () => {

    let Q = q.defer();

    describe('something', () => {

        it('should', (done) => {

            ...
        });
    });

    describe('something', () => {

        it('should', (done) => {

            ...
        });

        it('should', (done) => {

            ...

            Q.resolve('test complete');
        });
    });

    return Q.promise;
};

Parece funcionar muito bem, a menos que haja algo que eu não esteja considerando.

Devemos ainda ignorar o glob. Usar comandos bash não é uma solução de plataforma cruzada.

+1

Eu realmente gostaria de excluir node_modules . Exclusion parece um companheiro muito útil para recursive .

@godspeedelbow Por que esse diretório específico precisa ser explicitamente ignorado? Normalmente não ouço falar de node_modules em um diretório de teste.

FWIW, eu realmente poderia usar isso também. Eu tenho alguns projetos em que os testes escalam muito mais do que a própria biblioteca, e isso me permitiria organizá-los melhor (os acessórios pertencem a um diretório de teste IMHO).

Ignorar node_modules torna-se importante quando você está fazendo algo inesperado (como eu, onde mantenho os arquivos de especificação ao lado do arquivo que ele testa versus mantê-los em uma única pasta, longe do código que testa) ou se quiser para executar testes de unidade em um projeto principal e alguns de seus projetos incluídos (talvez sejam bibliotecas internas, não no repo npm, que você gostaria de testar), mas você não quer executar os testes de unidade dentro de suas próprias dependências .

Este problema já existe há quase um ano, então não tenho muita esperança de que seja implementado. É importante, na minha opinião, implementar porque as soluções alternativas requerem comandos de terminal específicos da plataforma ou você especifica explicitamente os padrões para cada diretório que deseja testar (portanto, diretórios adicionais precisam ser adicionados ao script de teste). Eu faria um fork e faria sozinho, mas usar o método hacky de especificar cada diretório e um padrão é apenas mais fácil do que encontrar tempo para implementá-lo no mocha.

@KrisSiegel Você sempre pode fazer src/**/*.js e src/**/*.spec.js . Vejo isso com mais frequência em projetos Go e Rust do que começar na raiz do projeto. Na verdade, o último é relativamente incomum.

Embora eu ache que eles estão apenas esperando que alguém dê um tempo para fazer isso sozinho. Não parece um patch difícil de criar (a menos que essa lógica seja uma bagunça espaguete de máquina de estado de código).

Não estou tão motivado a fazer isso pessoalmente porque estou realmente trabalhando em um framework de teste próprio, destinado a ser uma alternativa completa para Mocha, Jasmine, Tape, etc., embora mais simples e mais poderoso em seu núcleo. No entanto, ainda é um trabalho em andamento até mesmo para ATMs de projetos de brinquedo.

Estou usando o Mocha para inicializar o framework de maneira eficaz. Usei Chai inicialmente para as asserções até estabilizá-las (elas estão praticamente bloqueadas por API agora, já que estou usando as asserções do framework para testar a si mesmo).

Sim, é uma solução alternativa. Simplesmente não vejo muitos projetos JavaScript estruturados dessa forma, embora o mesmo possa ser dito sobre o emparelhamento da especificação e do arquivo de origem. Eu basicamente uso esse padrão, embora quando chego em projetos que já são muito grandes com seus próprios sistemas de construção personalizados, nem sempre é fácil alterá-lo.

Excluir é um padrão bastante básico que muitos utilitários têm. Acho que o mocha precisa :). Embora eu tenha a minha impressão, uma vez que esse problema foi resolvido com base em soluções alternativas específicas da plataforma, que não era desejado em vez de aguardar um patch. Se isso é algo que o pessoal do mocha realmente quer, se não for feito em algumas semanas, eu certamente poderia criar um patch.

@KrisSiegel Tenho quase certeza de que se alguém realmente criar um patch, ele provavelmente será mesclado, desde que não envolva alguma sintaxe especial não intuitiva ou sinalizador extra. FWIW, ainda não há um PR para _isso_, e o motivo pelo qual esse problema foi fechado foi muito fraco se você considerar o dependente da find apenas para executar alguns testes.

Ele pode estar fechado, mas uma situação semelhante já está acontecendo com o Node com Web workers , embora a implementação do Node seja ligeiramente diferente ( problema fechado , PR em andamento ).

1 pelo que vale a pena. Um projeto que eu construí não requer uma pasta app ou src , mas em vez disso tem uma quantidade variável de pastas nomeadas com diferentes implementações de interface. Também gostaria de manter meus testes agrupados para cada interface e não ser forçado a usar uma única pasta para testes.

Ser capaz de especificar arquivos a serem ignorados com .mochaignore ou outra opção seria o ideal, já que dessa forma eu poderia apenas executá-lo com um glob **/*.spec.js e não me preocupar que pudesse incluir testes do node_modules pasta.

Quase todas as outras ferramentas de construção permitem isso, temos .npmignore , .gitignore , .jshintignore , e jscs fornece uma opção para configurá-lo por meio de .jscsrc . Seria útil se o Mocha também o suportasse, pois mais e mais pessoas estão mudando para a organização de arquivos e pastas de componentes / recursos, longe da abordagem de gaveta de meias.

@isiahmeadows como outros mencionados, estou preso a uma estrutura de pastas que não posso alterar facilmente, portanto services/ , routes/ , etc. estão na raiz do projeto assim como node_modules é. Eu me inspirei para colocar os arquivos de teste ao lado dos arquivos que eles testam. Isso funciona muito bem, mas eu preciso de uma terceira ferramenta (seja linha de comando, gole ou outra coisa) para excluir node_modules modo que apenas meus próprios testes sejam testados.

Adoraria implementá-lo sozinho no mocha, se soubesse por onde começar :)

@godspeedelbow @adambuczynski Uma solução temporária :)

  "scripts": {
    "test": "mocha $(find . -name '*.spec.js' ! -ipath '*node_modules*')"
  }

Olá @danielstjules, obrigado! Tentei, mas por algum motivo find . -name '*.spec.js' ! -ipath '*node_modules*' encontrou apenas um arquivo de teste.

Você atualizou '*.spec.js' para se adequar ao padrão que seus testes seguem? Por exemplo, para combinar _todos_ os arquivos js, você usaria:

  "scripts": {
    "test": "mocha $(find . -name '*.js' ! -ipath '*node_modules*')"
  }

@danielstjules cheers, mas isso não funcionaria no windows eu acredito, e embora para este aplicativo não seja um problema, estou hesitante em colocá-lo.

Nesse ínterim, recorri a mover o código do aplicativo e os testes para uma subpasta app para que eu possa direcionar essa pasta para os testes e não me preocupar com node_modules ou outras pastas.

@danielstjules sim, todos os arquivos de teste estão no formato *.spec.js . Por algum motivo, não funcionou antes, mas agora quando funciona sem problemas. Obrigado por esta solução * NIX.

Eu quero ver isso feito para uma próxima especialização; apoiar especificamente .mochaignore parece razoável para mim

@boneskull Obrigado, seria ótimo.

Para a próxima versão principal, você também consideraria a implementação de um .mocharc mais "padrão" para opções de passagem, que podem ser colocadas na raiz do projeto, em vez de ter que usar um mocha.opts na pasta test ?

Isso tornaria a configuração do Mocha muito mais fácil e em linha com a forma como é feito com outras ferramentas por aí. Além disso, isso não nos forçaria a ter uma pasta test apenas para mocha.opts . (Colocamos todos os nossos testes junto com os módulos que eles testam).

@adambuczynski absolutamente. Não sou fã de mocha.opts

@adambuczynski ótimo comentário. Concordo, gostaria de ter um arquivo de opções .mocharc padrão também, também não uso mais um diretório de teste, pois é muito bom manter os testes ao lado do código.

+1, acho que excluir é realmente necessário.

@adambuczynski @boneskull A documentação indica que você pode usar --opts para especificar qualquer caminho para seu arquivo opts, embora não forneça nenhum exemplo. Estou usando isso em meu projeto atual e posso confirmar que funciona como mocha --opts .mocharc

Obrigado @GRUBES. No final, continuei usando a pasta test porque coloco meus auxiliares de configuração de teste lá também, mas é bom saber que é possível.

Glob tem uma opção de ignorar, então não deve ser um grande problema apenas adicionar uma opção de exlude e encaminhá-la para o glob ignore.

ignore Adicione um padrão ou uma matriz de padrões globais para excluir correspondências. Nota: os padrões de ignorar estão sempre no modo ponto: verdadeiro , independentemente de quaisquer outras configurações.

Não sei por que isso leva mais de um ano. :-)

@ inf3rno BTW, isso provavelmente teria sido resolvido muito antes se alguém realmente sentasse e escrevesse o patch.

@isiahmeadows Sim , mas não serei eu. : D

Isso ainda precisa de um PR? Eu ficaria feliz em adicionar isso, já que prefiro usar colocation de arquivo de teste em vez de vários diretórios para test e test-integration

2036, que é basicamente o mesmo tipo de coisa geral, apenas um arquivo em vez de uma opção de linha de comando, tem um PR # 2173

Talvez seja bom adicionar opções como --exclude .

Ou apoie algo como mocha test/*.js !test/_*.js

Descobriu o Glob out: mocha "./{,!(node_modules)/**/}*.test.js" para obter todos os arquivos * .test.js, exceto em node_modules, e mocha "./test/**/!(notThisOne).js" para obter tudo na pasta de teste e subpastas, exceto notThisOne.js

Veja também:
https://github.com/isaacs/node-glob#glob -primer
https://github.com/isaacs/node-glob/issues/62

@ScottFreeCode

Ao executar no terminal eu recebo

mocha "./{,!(node_modules)/**/}*.test.js"
-bash: !: event not found

Esse personagem deve ser escapado?

@mdumouchel Use aspas simples. Caso contrário, sim.

@isiahmeadows

Ainda obtendo erro

node_modules/mocha/lib/utils.js:630
        throw new Error("cannot resolve path (or pattern) '" + path + "'");
              ^
Error: cannot resolve path (or pattern) './{,!(node_modules)/**/}*.test.js'

Acabei usando apenas o comando find

mocha $(find . -type d -name node_modules -prune -o -name '*.test.js')

@mdumouchel Se você estiver usando a versão 2.x (ou seja, o que está no npm), não vai funcionar de qualquer maneira. O suporte começará em 3.x, IIRC.

Isso é estranho, pensei ter tentado no Bash e consegui usar aspas duplas. Alguém conhece uma sintaxe / escape que funcione tanto no Windows quanto no Bash?

Além disso, tenho quase certeza de que o erro "não é possível resolver o caminho" significa que o caminho não corresponde a nenhum arquivo em seu projeto; o caminho que dei funcionou na versão atual quando eu tinha arquivos de teste com nomes que terminam em ".test.js" ao lado dos arquivos de origem correspondentes, a menos que eu tenha errado ao copiá-lo do meu teste para o comentário do problema ...

Veja # 2173

Eslint faz um ótimo trabalho ignorando arquivos com --ignore-path (e .eslintignore ).
Consulte: http://eslint.org/docs/user-guide/command-line-interface#ignoring -files

Algo semelhante para mocha seria incrível: two_hearts:

Minha solução alternativa:

eslint "test/!(fixtures)/**/*.js" "test/*.js"

Minha estrutura de arquivo

.
└── src
└── test
    └── fixtures
        └── data.js
    ├── foo.js
    └── bar.js

Problema: Mocha me dá Error: cannot resolve path (or pattern) se algum dos 2 caminhos não corresponder a algo ..: deceped_relieved:

OK, então eu cedi. Isso simplesmente não é amigável.

Isso é o que acho que devemos fazer:

1. Apoie --exclude <glob-or-path>
2. Suporta _várias_ instâncias de --exclude
3. Combine todas as opções --exclude com todos os argumentos não opcionais em uma única lista (basicamente o que globby faz)
4. Carregue esses arquivos

Atualmente suportamos _n_ argumentos não opcionais, que podem ser todos globs, mas isso é apenas _aditivo_; isso não funciona como você esperava:

$ mocha 'src/**/*.spec.js' '!src/forbidden/**/*.spec.js'

Portanto, o acima deve funcionar, e --exclude é realmente apenas açúcar por ! .

Além disso, o suporte para .mochaignore (# 2036) parece bom, mas é um problema à parte. Deve haver um módulo 3p que podemos usar para ter um comportamento semelhante a .gitignore ; Tenho certeza que tudo o que ESLint está fazendo é bom o suficiente para nossos propósitos.

... e se não estiver claro, não use globs não citados na linha de comando; veja # 2355

Surpreendentemente, ainda não há opção como --ignore-path , além de colocar todos os testes em uma pasta tests , não há razão para que não possamos colocar os testes junto com os módulos.

+1
ignorar arquivos ou diretórios por padrão é um recurso muito útil

@isiahmeadows

Você sempre pode fazer src / / .js e src / /.spec.js

Não, você não poderia - a correspondência de padrão **/* está quebrada e não funciona recursivamente.

EDITAR: @ScottFreeCode tem a resposta abaixo

a correspondência de padrões **/* é quebrada e não funciona recursivamente.

Seus caminhos são citados ?

+1

Conforme descrito em https://github.com/zinserjan/mocha-webpack/issues/124 :

Dentro de src/ existe um arquivo chamado server.ts que dispara um servidor expresso e roda em segundo plano. O servidor normalmente está ativo durante a execução da cobertura, portanto, a porta já está em uso.

Portanto, não queremos que este e apenas este arquivo seja excluído.

http://remarkablemark.org/blog/2017/02/07/mocha-glob-pattern/

Expressando minha opinião, o mocha precisa ser ignorado porque mesmo depois de todo esse tempo, os mantenedores ainda precisam ser convencidos.

Mocha é canônico. por que não elevar o nível do conjunto de recursos de plataforma cruzada da estrutura de teste que todas as outras estruturas de teste aspiram ser? Devemos parar de aspirar a deixar tudo para Bash. Já é 2017.

Também vou apontar que as pessoas do Windows não têm nada equivalente ao !(glob) Bash (que na verdade é um Bash-ismo, nem mesmo o padrão POSIX).

Não deve haver nenhuma dependência de Bash no globbing do Mocha como está, uma vez que é processado por meio do módulo Glob JS. (Observação: pode ser necessário citar os caminhos para evitar os globs de processamento do shell de maneira diferente de como faria o Mocha, por exemplo, ** sem a extensão globstar ou o que quer que seja que o torne especial.)

@ScottFreeCode Você usa extglob: true quando usa glob? Se for esse o caso, então isso pode ser fechado com essa sintaxe como uma solução alternativa (uma vez que glob / minimatch oferece suporte com essa opção habilitada).

Parece que estamos apenas passando o caminho para o glob . Tenho certeza de que a negação está funcionando por meio de um padrão glob em algum momento, mas essa pode ter sido uma versão mais antiga do módulo. Em qualquer caso, temos testes para o comportamento de estrela dupla , então se alguém quiser enviar testes para confirmar que alguns padrões de negação também funcionam (ou se alguém encontrar alguma falha nos testes de globbing que já temos), seria ótimo .

No entanto, há uma vantagem definitiva em ter uma opção ignore / exclude explícita. Várias vantagens, na verdade:

• menos obscuro
• mais fácil evitar confrontos com caracteres especiais de sistemas operacionais diferentes e regras de citação
• uma lista de inclusão sem uma lista de exclusão é mais simples em muitos casos do que uma lista de inclusão com peças negadas

Queria apenas esclarecer que o status quo não foi feito para depender de nenhuma estrutura específica. ; ^)

uma lista de inclusão sem uma lista de exclusão é mais simples em muitos casos do que uma lista de inclusão com peças negadas

É verdade, e eu quase tinha me esquecido disso 😄

Qualquer pessoa que abordar este problema:

A solução agora é usar globs, pois isso deve ser suportado. Se alguém deseja este comportamento específico , envie um PR.

A opção --exclude funciona?
Não foi possível encontrar nos documentos .

@ sepo-one abri o PR para atualizar o documento.
Você pode ver todas as opções disponíveis em mocha -h .

Sim, tenho usado a versão antiga do mocha. A opção atualizada e --exclude está lá.
Docs deve ser atualizado de qualquer maneira, eu acho.

Obrigado @outsideris