Empresas
Empregos
  • Sobre nós
  • Soluções
    • Publicação de vagas
      Publique sua vaga e receba candidatos qualificados em 48h.
    • Avaliações de candidatos
      Mais de 500 testes técnicos e psicológicos, mais anti-fraude.
    • Headhunting
      Busca executiva personalizada do início ao fim.
    • Folha de Pagamento + EOR
      Dispersão de folha e EOR em mais de 15 países da LATAM.
  • Preços
  • Empregos

0

321
Visualizações
Testing using setTimeout(fn, 0). What this snippet of testing code does?

This is a snippet from a unit test file that use jest. The parse function returns a Promise after the parse is completed... But I cannot understand the use of that boolean flag (completedAsyncDummyTask).

it("parse is a promise that resolves with parser output", async () => {
  const parser = new Parser();
  let completedAsyncDummyTask = false;

  setTimeout(() => {
    completedAsyncDummyTask = true;
  }, 0);
  
  ...
  const test = await parser.parse(path.resolve(__dirname, "file.xyz"));
  expect(completedAsyncDummyTask).toBe(true);
  ...

});

Any ideas?

Thanks in advance.

about 4 years ago · Juan Pablo Isaza
1 Respostas
Responde à pergunta

0

I can't imagine what the purpose of the test would be. I can tell you what it's doing, but not why.

It's checking that the process of parser.parse(path.resolve(__dirname, "file.xyz")) fulfilled its promise while allowing at least one loop through the main ("macro") task queue, not just by doing all its work within the micro-task queue used by promise fulfillment.

If a promise is fulfilled right away, the main task queue never has a chance to run before code using await on it runs:

(async () => {
    setTimeout(() => {
        console.log("This comes second because it queues a macrotask");
    }, 0);
    await Promise.resolve();
    console.log("This comes first because the promise fulfillment never allowed the macro task queue to be processed.");
})();

But if it isn't, the main task queue might be processed at least once, which gives that timer callback a chance to set the variable.

The presence of the test suggests there's some code in the app that relies on that behavior, which would be quite odd. Even more odd that there's no comment explaining such an obscure test.


You might be tempted to think that since Promise.resolve returns a fulfilled promise, the await doesn't do anything at all and that code is just run synchronously. That's not true, even awaiting a fulfilled promise involves delaying subsequent code at least until the microtask queue has cycled, as we can see here:

let run = true;
let ticks = 0;
(async () => {
    while (run) {
        await Promise.resolve();
        ++ticks;
    }
})();
(async () => {
    setTimeout(() => {
        console.log(`This comes second because it queues a macrotask`);
    }, 0);
    console.log(`Before: ticks = ${ticks}`);
    await Promise.resolve();
    console.log(`After:  ticks = ${ticks}`);
    console.log("This comes first because the promise fulfillment never allowed the macro task queue to be processed.");
    run = false;
})();

about 4 years ago · Juan Pablo Isaza Relatório
Responde à pergunta
Encontrar trabalhos remotos

Descubra a nova forma de encontrar um emprego!

melhores empregos
Principais categorias de trabalho
Empresas
Postar vaga Preços Comercial
Jurídico
Termos e Condições Política de privacidade
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomende algumas ofertas para mim
Preciso de ajuda