Sinon: Caso contrário, versão 2.0

Gostaria de criar um novo site de documentação, baseado no trabalho que já está em /docs . Espero passar algumas horas nisso durante minhas férias na próxima semana.

@mroderick Se você tiver o trabalho empurrado em algum lugar, me avise. Posso ajudar com a documentação!

Atualizadas as caixas de seleção. Não tenho certeza se "Migrar sinon.sandbox" deve ser marcado, mas pelo menos o PR está fechado.

@jonnyreeves : não sei por que devemos remover sinon.test . Esta é uma caixa de areia em torno do teste que limpa todos os stubs criados e dispara automaticamente após o teste. Isso alivia as pessoas de muitas funções beforeEach e afterEach . Muito útil e tem pouco a ver com o teste de estruturas.

Os usuários precisariam ver uma alternativa fácil para isso ser removido em favor de outra coisa (melhor).

Eu nunca usei sinon.testCase sozinho, provavelmente porque sua API se encaixa no BusterJS (onde cada caso de teste é uma propriedade do conjunto de testes) e não no Mocha (onde cada teste é uma função anônima em execução no corpo do conjunto de testes )

@ fatso83 O principal problema que tenho com sinon.test é o fato de que ele depende do singleton sinon.config . Os usuários IMHO podem ter muito mais controle criando (e restaurando) uma sandbox nos ganchos beofreEach e afterEach sua estrutura de teste.

Se vamos manter sinon.test (e sinon.testCase ) na API pública; então precisamos abordar esses dois problemas - embora um usuário / suporte de longa data do sinon, eu seja novo em hackear seu projeto - como devemos chegar ao concenso?

@jonnyreeves OK, fez mais sentido quando você mencionou que dependia de sinon.config . IMHO explicitamente criar e restaurar sandboxes é bom, contanto que forneçamos isso como uma alternativa para pessoas que vêm de Sinon 1 e estão se perguntando o que aconteceu com sinon.test . Portanto, a doucmentação deve ser algo como

sinon.test

_Isto foi descontinuado na versão 2 em favor da criação explícita de uma área restrita. Veja link to sandbox ._

Estou totalmente interessado em uma API mais enxuta na versão 2, então coisas como typeOf , extends e sinon.test* poderiam ser melhor servidas por outros módulos NPM ou outra funcionalidade existente.

Acho que algo como npm install sinon-test e var sinonTest = require('sinon-test')(config); pode ser um substituto decente.

: +1: para mover utilitários como este em módulos npm separados. Menos código no core

Obrigado pela contribuição; Eu atualizei a visão geral no topo para refletir a discussão até agora (principalmente removendo pontos de interrogação, tornando as tarefas mais claras), por favor, dê uma olhada.

Além disso, poderíamos obter um fechamento semelhante em:

• removendo sinon.log e sinon.logError (ambos são usados ​​pelo fake_server; e provavelmente seriam melhor passados ​​como configuração para essas instâncias)
• removendo sinon.mock de 2.0

Obrigado

Nunca usei sinon.testCase , no entanto, sou um usuário frequente de sinon.test . Eu estou bem com isso indo para uma biblioteca separada, mas apenas para não esquecer: existem algumas pessoas usando estruturas de teste que não suportam beforeEach por design (por exemplo, fita) com o argumento de que essas configurações funções conduzem a casos de teste acoplados. Podemos causar muitos problemas para esses usuários se não houver uma substituição simples.

Acho que poderíamos oferecer algo assim como um caminho de migração:

sinon.test = require('sinon-test');

@mantoni : Ótima sugestão. Apenas atribuindo à propriedade test agora não utilizada, dá às pessoas o mínimo de trabalho ao incluir apenas uma linha extra em seus testes. Só temos que ter certeza de que o objeto sinon não está congelado (como em Object.freeze(sinon) ) em algum ponto ...

@jonnyreeves : em relação a sinon.mock , lembro que @mroderick sugeriu esperar até o lançamento do 2.0 antes de remover isso. Já há algum tempo sinalizamos que ele foi descontinuado, então não há problema em removê-lo após o lançamento do 2.0 IMHO. Mas, como já temos suporte para CommonJS, não me importaria de removê-lo antes do lançamento 2.0 _se_ extraímos o código em um módulo próprio. Então as pessoas poderiam apenas let sinon.mock = require('sinon-mock') , se quisessem.

Com relação a sinon.log* , não vejo razão para mantê-los como recursos públicos se pudéssemos fornecê-los como configuração quando necessário.

WRT fatorando sinon-test , apenas observe que precisaríamos permitir que os consumidores forneçam uma configuração, ou seja:

sinon.test = require('sinon-test').withConfig({ ... });

ou similar.

Acabei de localizar outra possível mudança de API ao criar um pacote sinon-test ; alguma ideia sobre o que deve acontecer a sinon.assert ? Novamente, isso não parece uma parte essencial da API do sinon para mim e pode ser mais adequado migrando para um pacote sinon-test junto com sinon.test e sinon.testCase ?

@ fatso83 @mantoni @cjohansen; Eu tenho uma versão funcional de um pacote sinon-test pronto para revisão - um de vocês poderia inicializar um repositório git vazio em sinonjs/sinon-test para que eu possa levantar um PR contra ele, por favor?

Obrigado

Aquilo foi rápido! https://github.com/sinonjs/sinon-test

@cjohansen, você poderia simplesmente enviar um README vazio para ele, por favor? Parece que não consigo levantar um PR no estado atual.

Feito

Obrigado, RP levantado - feedback bem-vindo: https://github.com/sinonjs/sinon-test/pull/1

@mroderick Se você tiver o trabalho empurrado em algum lugar, me avise. Posso ajudar com a documentação!

@spinningarrow isso seria ótimo. Eu criei # 991 para rastrear isso separadamente do resto do esforço. Estarei atualizando isso nos próximos dias com minhas ideias, e podemos continuar a partir daí.

Estamos tendo alguns problemas de vez em quando relacionados a simulações. Agora que @jonnyreeves fez o trabalho árduo de realmente extrair o módulo, não faria sentido mover o módulo para um repositório próprio? Então, poderíamos simplesmente mover todas as discussões relacionadas a simulações para lá e encerrar os problemas aqui. Isso é principalmente para aliviar o fardo da administração.

Estamos tendo alguns problemas de vez em quando relacionados a simulações. Agora que @jonnyreeves fez o trabalho árduo de realmente extrair o módulo, não faria sentido mover o módulo para um repositório próprio? Então, poderíamos simplesmente mover todas as discussões relacionadas a simulações para lá e encerrar os problemas aqui. Isso é principalmente para aliviar o fardo da administração.

Isso também significaria um fardo administrativo para manter esse repositório em sincronia com as ferramentas de desenvolvimento, etc.
Talvez devêssemos ter certeza de que temos ferramentas de desenvolvimento compartilhadas fáceis configuradas primeiro? cc: @mantoni

@mroderick @ fatso83 OK, vamos ver se conseguimos lançar o 2.0.

Eu atualizei a visão geral deste problema para cobrir o que considero ser todas as migrações pendentes (incluindo CJSification da suíte de teste, por favor, se você está lendo isto - ajuda!) - por favor, dê uma olhada e me diga se você concorda com o excelente trabalho.

Além disso, gostaria de obter um consenso sobre o seguinte:

1. Devemos remover typeOf e extend da API pública ( sinon. ), ou devemos esperar pelo Sinon 3.x que (presumo) passará por uma modernização da API .
2. Devemos remover o suporte / hacks do IE legado do 2.0? Isso _pode_ simplificar a migração, pois poderíamos eliminar o código 'fakeXDM' - não olhei de perto, então ainda não posso estimar esse trabalho.
3. O envio do novo site de documentos é um pré-requisito do lançamento 2.0? Estou preocupado que não tenha muita tração :)

Obrigado a todos.

@jonnyreeves : Você certamente esteve muito ocupado esta noite 😺. Tenho longas férias pela frente, então certamente poderia ajudar com as migrações pendentes da suíte de teste (há um "mas" abaixo).

Em relação aos seus pontos:

1. Eles devem ir. Achei que isso estava praticamente resolvido (ref, a visão geral acima).
2. Vamos apenas definir "IE legado" primeiro. Versões <10 ou todo o pacote sinon-ie ? O IE9 ainda trazia uma alternativa de CORS esquisita chamada XDR. Se houver alguém ainda com o objetivo de oferecer suporte às versões do IE lançadas antes de 2012, eles sempre poderiam usar o branch 1.x, eu acho. Não tem certeza do que você chama de XDM? Não tenho certeza de quais versões de navegador sinon-ie são necessárias, portanto, não posso ser muito bombástico sobre o pacote não ser necessário. Devemos estar certos das consequências.
3. A documentação _é_ um ponto problemático agora, mas não tenho certeza do que dizer aqui. Eu poderia começar a cavar em # 991 antes de ajudar com os outros pontos acima. Ter um lugar para empurrar os documentos tornaria a vida melhor.

Curioso para saber qual é o status disso? Não parece que houve muito progresso desde ~ 6 meses atrás; No momento, estou dependendo de um pré-lançamento por várias razões (o suporte para o funcionamento do símbolo é enorme) - não me refiro a empurrar, mas um simples 'há umlinha do tempo '/' ainda não há linha do tempo 'seria ótimo! <3

@ELLIOTTCABLE como não temos financiamento, não há um

1. Mesmo que você veja "... referenciado em 8 de julho de 2016" acima, isso significa apenas que o primeiro comentário na lista é dessa data. A última edição, # 1235, referenciou isso "12 dias atrás".
2. A lista de problemas está quase completa - ao contrário de meio ano atrás.

Então ... estamos chegando a algum lugar, mas supervisionar as correções de bugs da versão anterior, bem como um suprimento constante de novos recursos, consome muito do nosso tempo de manutenção. Só de pesquisar e escrever isso levou meia hora no final 😅

Basicamente, depois de examinar a lista acima, existem apenas dois problemas principais que permanecem:

• "Migrar fake_server e amigos" (90% resolvido, apenas um pouco restante - veja acima).
• Publique o site (veja # 1220: uma tarefa pequena e super fácil e uma tarefa média disponível)

Acho que a maioria das outras marcas de verificação reveladas acima está relacionada a versões antigas do IE (6 a 10) que tenho certeza de que não serão suportadas, com base nas discussões em # 1221, portanto, podem ser ignoradas. Abordarei isso agora.

@ sinonjs / sinon-core: o comentário anterior me deixou ciente de que temos alguns problemas acima que provavelmente não serão concluídos com base na discussão em # 1221:

1. Remover suporte / soluções alternativas para o IE legado?
2. Corrigindo xdomain

Se importa se eu criar um PR apenas para remover os bits do IE legado, se não formos tocá-los de qualquer maneira? Eu presumiria que xdomain pode acabar no aterro histórico também, já que isso foi principalmente um hack do CORS apenas para IE, então pode ser removido?

@ fatso83 Ahhhh, k. Eu perdi os comentários atualizados sobre os problemas mencionados. Espero que revisar isso para mim tenha sido útil para você!

Não relacionado: parece que parte disso está abandonando o suporte para o IE6. Isso é lamentável. Bem, c'est la marche du progrès! / =

Basicamente, estamos lá, o site de documentos tem seu próprio problema.

Ei pessoal - algo nos impede de marcar 2.0 como a versão sinon "estável" e matar 1.x? :)

Acho que queríamos # 1297 como a última coisa.

ETA nisso? Sugiro que enviemos o mais tardar na semana que vem, adiando esse recurso se não estiver pronto.

Vocês são lindos. <3