Le travail en open source me fait apprécier les tests de logiciels. Ce n’est pas un exercice théorique.

L’approche systémique Peut-être que le plus gros aspect de la construction de systèmes que j’ai appris à apprécier depuis que j’ai changé mes activités académiques pour me concentrer sur le développement de logiciels open source, c’est l’importance des tests et de l’automatisation des tests. Dans le milieu académique, il n’est pas exagéré de dire que nous enseignons aux étudiants comment tester uniquement dans la mesure où nous avons besoin de cas de test pour évaluer leurs solutions, et nous faisons exécuter des benchmarks de performances à nos étudiants de troisième cycle pour collecter des données quantitatives pour nos articles de recherche, mais c’est à peu près tout. Il y a certainement des exceptions, par exemple des programmes axés sur l’ingénierie logicielle, mais mon expérience est que l’importance accordée aux tests dans le milieu académique est mal alignée sur son importance dans la pratique. Une large partie de la bande passante de l’équipe de l’approche systémique a été consommée ces derniers mois par des efforts pour accroître la robustesse et la facilité d’utilisation d’Aether, une plateforme de bord nuage permettant la prestation de services privés 5G. Et bien sûr, vous ne pouvez pas avoir une plateforme robuste et utilisable sans tests, ce qui s’est avéré être un point douloureux. C’est donc cela qui a fourni l’inspiration pour la dernière colonne, alors que nous essayons d’apporter la vision systémique aux tests. J’ai dit que j’appréciais le rôle des tests logiciels, mais je ne suis pas sûr de les comprendre avec suffisamment de clarté et de profondeur pour les expliquer à quiconque d’autre. Comme c’est la nature de notre état d’esprit de l’approche systémique, j’aimerais mieux comprendre les «pourquoi», mais surtout ce que je vois et j’entends beaucoup de jargon: tests unitaires, tests de fumée, tests de saturation, tests de regression, tests d’intégration, etc.