Il codice errato ha molte caratteristiche uniche. In questo articolo, esamineremo ciascuno e cosa sono. Esaminiamo odori di codice più generali.

In questo articolo vedremo come denominare le cose correttamente e come scrivere un test che abbia una copertura elevata e veloce.

Denominazione

Usa nomi lunghi per ambiti lunghi

Se l'ambito è lungo, il nome dovrebbe essere più lungo rispetto a se si trovano in un ambito breve.

Le variabili con nomi brevi perdono il loro significato su lunghe distanze.

Evita codifiche

I nomi non dovrebbero essere codificati con le informazioni sull'ambito. Dovremmo evitare prefissi inutili.

Tuttavia, i tipi nei nomi possono essere utili in JavaScript poiché le variabili e le costanti hanno tipi dinamici.

I nomi dovrebbero descrivere gli effetti collaterali

Se un pezzo di codice commette effetti collaterali, il nome dovrebbe rispecchiarlo. Ad esempio, se abbiamo la seguente funzione:

let foo;
const getFoo = () => {
  if (!foo) {
    foo = {}
  }
  return foo
}

Invece, dovremmo nominarlo setFooIfNotExistAndGetFooper tenere conto di entrambe le azioni.

Test

Test insufficienti

Dobbiamo assicurarci di avere una copertura di test sufficiente in modo da sapere che il codice e le diramazioni funzionano.

Inoltre, i nostri test dovrebbero prendere in considerazione sia i casi positivi che quelli negativi.

I casi limite e limite dovrebbero anche avere test per testare casi che potrebbero rompere il nostro codice.

Usa uno strumento di copertura

Gli strumenti di copertura dei test ci dicono per cosa abbiamo test e cosa necessita ancora di copertura del test.

Ci dicono anche quali rami del nostro codice hanno una copertura di test.

Non saltare i test banali

Sono facili da scrivere e servono come buona documentazione.

Un test ignorato è una domanda su un'ambiguità

Un test ignorato è sempre discutibile. Non sappiamo perché vengono saltati, quindi chiariamo il motivo per cui saltiamo un test.

Testare le condizioni al contorno

Il test delle condizioni al contorno è importante poiché il codice spesso interrompe le condizioni al contorno.

Testare in modo esauriente Near Bugs

Se un pezzo di codice ha dei bug, allora dovremmo testare di più quei casi.

I modelli di fallimento si stanno rivelando

I modelli che i casi di test falliscono possono dirci molto su cosa sta infrangendo il nostro codice.

I casi che non riescono a raccontare di solito hanno uno schema, come quando falliscono con 5 o più caratteri passati o qualcosa del genere.

I test dovrebbero essere veloci

I test lenti sono una tortura da eseguire. Vengono semplicemente ignorati e non verranno scappati. Dovremmo renderli il più velocemente possibile, soprattutto perché ce ne saranno molti.

Conclusione

Dovremmo nominare le cose in modo univoco. Se ci sono effetti collaterali, allora dovremmo descriverli.

Inoltre, i test dovrebbero coprire bug e casi limite e dovrebbero essere eseguiti velocemente.

Possiamo usare uno strumento di copertura per avere un'idea chiara di quali parti di codice sono coperte dai test.