Sinon: Como podemos substituir a rejeição criando um novo objeto de erro?

Criado em 1 fev. 2018 · 6Comentários · Fonte: sinonjs/sinon

https://github.com/sinonjs/sinon/blob/4310343393b16b92b56526ab4614da4eb2886efa/lib/sinon/default-behaviors.js#L176

Estou mantendo alguns códigos que rejeitam strings e isso está criando problemas durante o teste. minhas capturas de bluebird não estão se comportando corretamente.

bluebird.rejects('Something')
    .catch(e => e === 'Something' /* true */, () => console.log(typeof e) /*string*/)
    .catch(() => console.log('should not be here'));

Porém, usar sinon.stub().usingPromise('bluebird').rejects('Something'); acaba criando um objeto de erro com o nome Something. Nem um pouco esperado.

Antes que alguém diga que apoiamos apenas Promessas nativas, vamos investigar o que eles fazem!

Promise.reject('Something')
     .catch(e => {
        console.log(e === 'Something'); // true
        console.log(typeof e); // string
    });

Hmmm, eles não criam uma classe Error, eles apenas lançam a exceção que foi dada como um lançamento.

try { 
    throw 'Something'; 
} catch (e) { 
    console.log(e === 'Something');  // true
    console.log(typeof e); // string
}

Bug Help wanted pinned

Fonte

JemiloII

Comentários muito úteis

Utilidade do rastreamento de pilha e discussões sobre se deve-se criar objetos de erro à parte, eu concordo que geralmente

const example = sinon.stub().rejects(something);

deve se comportar da mesma forma que

const example = () => Promise.reject(something);

Atualmente, este não é o caso se something for uma string. Eu diria que o comportamento atual é um bug.

mantoni em 8 set. 2020

👍4

Todos 6 comentários

Antes que alguém diga que apoiamos apenas Promessas nativas, vamos investigar o que eles fazem!

Isso é uma falácia do espantalho . Você sabe muito bem que apoiamos bibliotecas prometidas, conforme você as usa em seu exemplo.

Os mantenedores do Sinon estão totalmente cientes de como as promessas do JavaScript funcionam, incluindo que Promise.reject() passará qualquer coisa que você passar para ele.

Estou mantendo algum código que rejeita strings

Na minha opinião, rejeitar promessas com String vez de Error é realmente um desserviço ao Desenvolvedor Futuro, que tem que depurar o que escrevemos hoje. Strings não são muito úteis para depuração, pois não capturam rastreamentos de pilha. Error por outro lado, sim. Portanto, acho que o comportamento de rejects() é desejável, pois torna mais fácil usar o depurador para descobrir rapidamente o que deu errado.

Parece que você discorda, mas a única afirmação que você fez é que a Sinon não atende às suas expectativas. Se você acha que o comportamento padrão deve ser alterado, poste argumentos sobre o motivo, tendo em mente que a mudança pode afetar muitos usuários.

Se houver argumentos sólidos para mudar o comportamento padrão, não posso imaginar que nenhum dos mantenedores do Sinon se oporia a uma solicitação de pull para mudá-lo.

mroderick em 11 fev. 2018

👍1

Este problema foi marcado automaticamente como obsoleto porque não teve atividades recentes. Ele será fechado se nenhuma outra atividade ocorrer. Obrigado por suas contribuições.

stale[bot] em 12 abr. 2018

Eu diria que pode haver opiniões divergentes sobre se um rastreamento de pilha é ou não realmente útil em determinados cenários. Na minha situação particular, eu realmente não me importo com o rastreamento de pilha, eu só me importo com a mensagem de erro e, em seguida, passá-la para outro lugar. Portanto, escrevi um código para lidar com os motivos de rejeição do tipo String e Error. No entanto, uma vez que o sinon faz a coerção String -> Error para mim, não posso testar o branch do meu código que lida com strings. Como tal, não consigo obter cobertura total

dtom90 em 8 set. 2020

Utilidade do rastreamento de pilha e discussões sobre se deve-se criar objetos de erro à parte, eu concordo que geralmente

const example = sinon.stub().rejects(something);

deve se comportar da mesma forma que

const example = () => Promise.reject(something);

Atualmente, este não é o caso se something for uma string. Eu diria que o comportamento atual é um bug.

mantoni em 8 set. 2020

👍4

Eu concordo.

JemiloII em 17 set. 2020

Este problema foi marcado automaticamente como obsoleto porque não teve atividades recentes. Ele será fechado se nenhuma outra atividade ocorrer. Obrigado por suas contribuições.

stale[bot] em 25 dez. 2020

Esta página foi útil?

0 / 5 - 0 avaliações