Le code procédural des tests unitaires est-il efficace?

Sur un projet en cours, les pouvoirs en place veulent avoir des tests unitaires intégrés dans notre cycle de développement pour éviter la quantité constante de bogues qui semblent s'infiltrer dans notre code. Le problème est que le code spaghetti est procédural à 95%, avec lequel je n'ai jamais fait de tests unitaires (toute mon expérience avec les tests unitaires a été avec le code POO)

Donc, ma question en bref est-il judicieux de procéder à des tests unitaires avec notre base de code actuelle, ou de suggérer qu'il soit reporté jusqu'à ce que l'application ait été migrée vers un cadre OOP approprié?

PS: Bien que j'aie essayé de définir cette question comme indépendante du langage, je pense que le fait d'indiquer que l'application en question utilise PHP et javascript aidera à fournir des réponses plus spécifiques qui pourraient répondre à cette question car, par expérience, cet événement se produit le plus avec de telles applications.

Les tests unitaires fonctionnent bien avec les objets, d'autant plus qu'ils offrent de nombreuses fonctionnalités fantaisistes, comme des objets fantaisie, ce qui permet de créer de meilleurs tests plus rapidement.

Cela étant dit, rien n'interdit de faire des tests unitaires sur une base de code procédurale . Dans la POO, la plupart des tests unitaires testent des méthodes en leur transmettant certains paramètres et en attendant soit un résultat, soit une exception d'un type spécifique. Cela peut être fait aussi loin avec le code procédural; juste qu'au lieu de tester les méthodes, vous testerez les fonctions .

Notez que vous devrez:

• Isolez les fonctions que vous devez tester et celles dont vous n'avez pas besoin. En POO, c'est simple: les méthodes privées n'ont pas à être testées car les appelants ne pourront jamais y accéder directement. Il y a des chances, dans votre code procédural, que certaines fonctions soient comme ça et n'aient pas besoin de tests.

• Pensez à la portée mondiale . Le problème existe également dans la POO, mais si vous dites que vous devez tester le code de spaghetti, les chances sont que les personnes qui ont écrit ce code ont de mauvaises habitudes, comme utiliser trop la portée globale et faire des choses folles comme changer $_GETou $_POSTcréer des tableaux à l' intérieur les fonctions.

• Traitez le code en dehors des fonctions. C'est un cas plus compliqué, mais toujours possible. Soit vous require_onceune page pour voir ce qui se passe et intercepter la sortie via ob_start/ob_get_clean , soit vous faites une requête HTTP à partir de la suite de tests et analysez la réponse en analysant le code HTML. Ce n'est pas vraiment un test d'interface utilisateur: ici, peu importe si un bouton sur une page apparaît à gauche ou à droite ou si un lien est en grosses majuscules rouges ou en petites bleues. Ce qui vous importe, c'est de trouver certains éléments HTML via DOM et de comparer leur contenu à celui attendu.

• Testez les codes de réponse . require_onceavec la mise en mémoire tampon de sortie, c'est bien, mais vous devez également tester comment l'application Web gère les erreurs. Par exemple, si le résultat attendu d'un test est 404 Introuvable, vous devez effectuer une requête HTTP afin de connaître la réponse.

suggérer qu'il soit reporté jusqu'à ce que l'application ait été migrée vers un cadre OOP approprié

Mettez en place des tests automatiques avant de migrer vers une autre plate-forme, pas après. Ajoutez d'autres tests pendant la migration, pas après. Si ces tests sont des "tests d'intégration" ou des tests unitaires, vous devez décider vous-même, mais vous pouvez généralement utiliser votre framework de test xUnit préféré pour les deux types.

Le moyen le plus efficace pour démarrer les tests unitaires consiste à identifier la classe d'erreurs les plus fréquentes ou les plus coûteuses. Créez ensuite des tests qui ciblent ces erreurs.

La façon dont ces tests seront mis en œuvre différera entre les paradigmes et les langues. La plus grande chose qui affectera votre capacité à effectuer des tests unitaires est la qualité du code; moins le paradigme utilisé. N'oubliez pas que les tests unitaires consistent à tester une "unité" de code de manière isolée. Tout ce qui affecte votre capacité à isoler des "unités" de code rendra les tests plus difficiles.

• utilisation des globaux
• Effets secondaires
• code étroitement couplé
• code mal couplé
• un grand nombre de conditionnels
• "unités" mal conçues

Tous ces éléments auront un impact plus élevé sur la difficulté des tests que le paradigme linguistique.

Chaque fois que vous avez une situation où vous pouvez tester des parties de votre code automatiquement, les tests unitaires peuvent être efficaces. Ainsi, la question n'est pas de savoir si le code procédural peut être testé de manière efficace, la question est de savoir si CE code peut être testé de manière unitaire. Cela dépendra de la quantité d'états qu'il lit et de la quantité d'états qu'il définit. Idéalement, la réponse aux deux est zéro, mais si ce n'est pas le cas, vous pouvez toujours la tester.

Comme toujours, vous devez peser la confiance que le code est correct par rapport au coût d'acquisition de cette confiance. Gardez à l'esprit qu'une partie du gain pour les tests unitaires identifie explicitement les dépendances, et en ce sens, il est encore plus efficace de tester le code procédural unitaire par rapport au code OOP.

Je ne pense pas qu'il soit possible de faire de vrais tests unitaires contre du code procédural. Le problème principal étant que chaque procédure aura probablement de nombreuses dépendances qui ne peuvent pas être éliminées. Au mieux, les tests seront des tests d'intégration. J'ai fait une chose similaire il y a plusieurs lunes avec les modules VB6 et les modules VBA dans MS Access.

Cela dit, si vous pouvez mettre un échafaudage de test autour des méthodes qui causent le plus de douleur, cela doit être utile, non?