1

Pitch: DoesItHold — um await ausente e três testes para revisar a correção

O exercício abaixo tem um bug intencional. Ele é pequeno de propósito: serve para quem está começando com JavaScript praticar como explicar uma correção, mesmo quando uma IA consegue sugeri-la rapidamente.

async function fetchUser() {
  return { name: 'Ana' };
}

async function loadName() {
  const user = fetchUser();
  return user.name;
}

Antes de mudar o código: qual valor loadName() resolve? O que muda se fetchUser() falhar?

A resposta e como verificá-la

fetchUser() devolve uma Promise. Declarar a função externa como async não faz a variável user receber automaticamente o resultado resolvido. Neste exemplo, lemos name da Promise e a função resolve para undefined.

A correção é esperar no ponto em que precisamos do usuário:

const user = await fetchUser();
return user.name;

Para conferir o comportamento sem depender de uma API, podemos passar fetchUser como argumento. Salve o exemplo abaixo em await-review.cjs e execute node await-review.cjs:

const assert = require('node:assert/strict');

async function brokenLoadName(fetchUser) {
  const user = fetchUser();
  return user.name;
}

async function loadName(fetchUser) {
  const user = await fetchUser();
  return user.name;
}

async function main() {
  const succeeds = async () => ({ name: 'Ana' });
  assert.equal(await brokenLoadName(succeeds), undefined);
  assert.equal(await loadName(succeeds), 'Ana');
  await assert.rejects(
    () => loadName(async () => { throw new Error('unavailable'); }),
    /unavailable/
  );
  console.log('3 behavior checks passed: original result, corrected result, rejection propagation.');
}
main().catch(error => { console.error(error); process.exitCode = 1; });

Os três checks cobrem o resultado da versão com defeito, o resultado corrigido e a propagação de uma rejeição. Não são uma prova de que qualquer implementação esteja correta: ainda precisamos definir os contratos da aplicação.

A decisão de produto por trás do exercício

Sou o criador do DoesItHold, um produto de prática de debugging. Neste guia, a escolha foi deixar o caso e a explicação abertos, antes de pedir cadastro. A pessoa consegue avaliar se o raciocínio é útil, executar o exemplo e só depois decidir se quer praticar no produto.

Também escolhemos não apresentar o feedback como uma certificação. Uma correção precisa ser entendida e testada; uma resposta bem escrita, produzida por pessoa ou IA, não substitui essa verificação.

Neste caso, await suspende esta continuação assíncrona, sem bloquear a thread inteira. Quando a Promise rejeita, a função corrigida propaga o erro. Uma aplicação real precisa escolher onde tratar esse erro. Colocar um timeout ou trocar por optional chaining não resolve a dependência de dados.

Se quiser continuar

O guia gratuito do DoesItHold tem a explicação e a entrada para a prática. O guia pode ser lido sem conta.

Estou buscando os primeiros devs adultos JS/TS em início de carreira para uma rodada voluntária. Se testar, me conte em qual ponto o exercício ajudou ou ficou simples demais. Não precisamos de código privado.

Referência: MDN — await.

Texto preparado com assistência de IA; o script foi executado localmente para conferir os três comportamentos descritos.

Carregando publicação patrocinada...
1

Dá pra mostrar no exercício que esse bug nem precisa de teste pra aparecer: com // @ts-check no topo do arquivo, o VS Code já marca o user.name dizendo que a propriedade não existe em Promise e ainda pergunta se faltou um await. Não substitui o teste da rejeição, mas é um hábito bom pra quem tá começando em JS.

1

Boa! O // @ts-check complementa bem o exemplo: ajuda a perceber o await ausente no editor, enquanto o teste da rejeição confere o comportamento quando a chamada falha. Obrigado pela sugestão!

1