No, You Don’t Need To Struggle Testing React

Writing tests in such an envi­ron­ment need to satisfy two rules:

1. Writing specs should take the least amount of time possible.
2. Each spec should test as much code as possible.

Now I’ve proba­bly already lost half of you reading this. « Each spec should test as much as possible? How do you isolate failures?” Yeah, yeah, I agree, but at the end of the day, the only purpose of my testing suite is to make sure that the little CircleCI dot on Github turns red whene­ver I merge a brea­king change.

— Stephen Grider

C’est voir un seul côté du miroir, et au travers de lunettes de soleil.

Le test auto­ma­tisé n’est pas là que pour l’in­té­gra­tion conti­nue. Il est aussi là pour prou­ver que le code qu’on a produit corres­pond bien à ce qui est souhaité. Il est aussi là pendant le déve­lop­pe­ment pour ne pas faire du pas à pas et du test manuel encore et encore jusqu’à ce que ça semble fonc­tion­ner. Il est là pour permettre à un tiers de comprendre et repro­duire.

Je n’ai rien contre le fait d’avoir un scéna­rio avec plusieurs asser­tions – qui est le fond du billet cité – mais avec des tests les plus gros possibles, on loupe la moitié des objec­tifs. Pire : on se créé une jolie dette tech­nique pour quand on aura quelque chose à chan­ger. Au lieu de reti­rer ou modi­fier quelques tests bien précis, on a un gros truc qui passe au rouge, qu’on va devoir modi­fier au risque d’obli­té­rer des cas limites.