Un mauvais code a de nombreuses caractéristiques uniques. Dans cet article, nous examinerons chacun d'eux et ce qu'ils sont. Nous examinons les odeurs de code plus générales.

Dans cet article, nous verrons comment nommer les choses correctement et écrire un test qui a une couverture élevée et rapide.

Appellation

Utiliser des noms longs pour les longues étendues

Si la portée est longue, le nom doit être plus long que s'ils sont dans une portée courte.

Les variables avec des noms courts perdent leur signification sur de longues distances.

Évitez les encodages

Les noms ne doivent pas être encodés avec des informations d'étendue. Nous devons éviter les préfixes inutiles.

Cependant, les types dans les noms peuvent être utiles en JavaScript car les variables et les constantes ont des types dynamiques.

Les noms doivent décrire les effets secondaires

Si un morceau de code provoque des effets secondaires, le nom doit le refléter. Par exemple, si nous avons la fonction suivante:

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

Au lieu de cela, nous devrions le nommer setFooIfNotExistAndGetFoopour prendre en compte les deux actions.

Des tests

Tests insuffisants

Nous devons nous assurer que nous avons une couverture de test suffisante pour que nous sachions que le code et les branches fonctionnent.

De plus, nos tests doivent prendre en compte à la fois les cas positifs et négatifs.

Les cas de limite et de bord devraient également avoir des tests pour tester les cas qui peuvent casser notre code.

Utilisez un outil de couverture

Les outils de couverture de test nous indiquent ce pour quoi nous avons des tests et ce qui nécessite encore une couverture de test.

Ils nous indiquent également quelles branches de notre code ont une couverture de test.

Ne sautez pas les tests triviaux

Ils sont faciles à rédiger et constituent une bonne documentation.

Un test ignoré est une question sur une ambiguïté

Un test ignoré est toujours discutable. Nous ne savons pas pourquoi ils sont ignorés, nous expliquons donc clairement pourquoi nous sautons un test.

Conditions aux limites du test

Tester les conditions aux limites est important car le code rompt souvent autour des conditions aux limites.

Tester de manière exhaustive près des bogues

Si un morceau de code a des bogues, nous devrions tester ces cas davantage.

Des modèles d'échecs se révèlent

Les modèles qui échouent les cas de test peuvent nous en dire long sur ce qui brise notre code.

Les cas qui échouent ont généralement un modèle, comme quand ils échouent avec 5 caractères ou plus passés ou quelque chose du genre.

Les tests doivent être rapides

Les tests lents sont une torture à exécuter. Ils sont simplement ignorés et ne seront pas exécutés. Nous devrions les faire le plus vite possible, d'autant plus qu'il y en aura beaucoup.

Conclusion

Nous devons nommer les choses de manière non ambiguë. S'il y a des effets secondaires, nous devons les décrire.

En outre, les tests doivent couvrir les bogues et les cas limites et ils doivent s'exécuter rapidement.

Nous pouvons utiliser un outil de couverture pour avoir une idée claire des morceaux de code couverts par les tests.