Existe-t-il des cadres de tests unitaires indépendants de la langue? [fermé]

11

J'ai toujours été sceptique quant à la réécriture du code de travail - le portage de code ne fait pas exception à cela. Cependant, avec l'avènement du TDD et des tests automatisés, il est beaucoup plus raisonnable de réécrire et de refactoriser le code.

Est-ce que quelqu'un sait s'il existe un outil TDD qui peut être utilisé pour porter l'ancien code? Idéalement, vous pourriez faire ce qui suit:

Rédigez des tests unitaires indépendants de la langue pour l'ancien code qui réussit (ou échoue si vous trouvez des bogues!).
Exécutez des tests unitaires sur votre autre base de code qui échouent.
Écrivez du code dans votre nouveau langage qui réussit les tests sans regarder l'ancien code.

L'alternative serait de diviser l'étape 1 en "Écrire des tests unitaires dans la langue 1" et "Port tests unitaires dans la langue 2", ce qui augmente considérablement l'effort requis et est difficile à justifier si l'ancienne base de code va cesser d'être maintenue après le port (c'est-à-dire que vous n'obtenez pas l'avantage d'une intégration continue sur cette base de code).

EDIT: Il convient de noter cette question sur StackOverflow.

unit-testing language-agnostic porting

— Bringer128
source

Fournissez un protocole de commande en texte pur, puis utilisez-le expectpour implémenter vos tests.

— SK-logic

@ SK-logic dont je n'avais pas entendu parler expect. Si vous avez un système hérité de style Unix qui communique avec les canaux utilisant stdin et stdout, cet outil peut être utilisé à coup sûr. En fait, il serait également assez facile de tester avec n'importe quel langage de script.

— Bringer128

pourquoi l'héritage? Vous pouvez également avoir un système moderne de style Unix. Quoi qu'il en soit, il n'existe jamais de justification valable pour ne fournir une interface de script à aucun élément de fonctionnalité.

— SK-logic

@ SK-logic Désolé de ne pas être clair. J'ai dit "hérité" car le portage se fait généralement de legacy language xà fancy new language y. Je n'essayais pas d'impliquer quoi que ce soit à propos d'Unix!

— Bringer128

@ Bringer123, soit dit en passant, ma petite astuce pour faire ce genre d'intégration de type Unix sans aucun support Unix décent (par exemple, pas de canaux appropriés) est d'incorporer un langage de script et de fournir un accès à son REPL via le port TCP (avec REPL s'exécutant dans un thread séparé). C'est à la fois un puissant outil de débogage et un moteur d'automatisation des tests. Et cette approche fonctionne littéralement avec tout (un langage de script intégré peut être vraiment minuscule, il peut même être un Forth dans un scénario de ressources limitées).

— SK-logic

6

Je ne pense pas qu'il soit possible d'écrire des tests unitaires dans une langue différente.

Cependant, ce que vous pouvez faire, c'est écrire des tests d'intégration / acceptation / interface utilisateur / whaterver_you_name_it qui seraient de très haut niveau et ne seraient pas liés à la langue avec laquelle votre logiciel est écrit.

Si votre application est un service Web, vous pouvez la tester avec la langue de votre choix, à condition qu'elle prenne en charge votre protocole. Si votre application s'exécute dans un navigateur, vous pouvez utiliser du sélénium (c'est le premier qui m'est venu à l'esprit, mais il y en a d'autres. Etc. Il pourrait y avoir des cas où cela ne fonctionnerait pas, j'imagine (peut-être du matériel), tout dépend sur le type d'application sur laquelle vous travaillez.

Bien sûr, vous n'aurez pas la même couverture que vous auriez avec des tests de niveau unitaire (à moins de passer beaucoup de temps), mais au moins, vous auriez un harnais de test.

— David
source

+1 pour les tests automatisés de haut niveau. Ceux-ci en valent certainement la peine.

— Bringer128

1

"Je ne pense pas qu'il soit possible d'écrire des tests unitaires dans une autre langue." : exemple de compteur: dans .NET, vous pouvez écrire des tests unitaires de C # dans Visual Basic (ou tout autre langage compatible .NET). Il y a quelques années, cela a même été promu par Microsoft comme une meilleure pratique, car cela réduit le risque de faire dans le code et teste la même erreur liée au langage (et en particulier la méconnaissance relative du programmeur à ce sujet). D'accord, on n'écrira pas de tests unitaires dans Fortran pour tester le code PHP.

— Arseni Mourzenko

2

Je pense que ce qui se rapproche le plus de votre idée, ce sont les cadres de tests unitaires sur des écosystèmes basés sur des machines virtuelles tels que la machine virtuelle Java. Au moins Scala (et je crois que Groovy aussi - je ne suis pas sûr de Clojure) est presque parfaitement interopérable avec Java. Autrement dit, le code Scala peut être testé avec JUnit et le code Java peut être testé avec ScalaTest. De cette façon, vous pouvez (progressivement ou immédiatement) réécrire le code Java dans Scala et continuer à utiliser les mêmes anciens tests unitaires Java pour vérifier son exactitude. (Ou l'inverse - bien que je ne puisse pas imaginer une raison valable pour migrer de Scala vers Java.)

Il en est probablement de même pour les langages de la CLI .NET, par exemple C #, F #, ASP.NET et al.

En dehors d'un VM / CLR, cependant, c'est plus difficile. En théorie, on pourrait compiler des tests unitaires et / ou du code sous test dans un autre langage tel que C (comme cela était et est courant avec de nouveaux langages tels que les premiers C ++, etc.), mais je n'ai entendu parler de personne essayant cela spécifiquement avec tests unitaires.

— Péter Török
source

1

Je suppose que cela montre le problème avec ma question. S'ils peuvent interagir facilement, pourquoi porter? Et s'ils ne le peuvent pas, la barrière de la langue rend impossible la réalisation de tests unitaires multilingues.

— Bringer128

@ Bringer128, les partisans de la nouvelle race de langages JVM affirment que des problèmes spécifiques peuvent être résolus plus rapidement, avec un code beaucoup moins propre et plus propre qu'en Java. Mon expérience limitée avec Scala le confirme jusqu'à présent.

— Péter Török

Groovy interagit également avec Java.

— user281377

1

Un tel framework n'existe pas, car il doit être écrit dans la langue du code utilisé.

Par exemple, un framework pour tester le code c ++ doit être écrit en c ou c ++. Utiliser un framework écrit en c ++ pourrait, mais il ne va pas tester le code ac s'il utilise des fonctionnalités c ++.

— BЈовић
source

1

Les méthodologies varient, mais dans mon cas, une grande partie de mes tests TDD ont tendance à être de type «test d'intégration», par opposition au «test unitaire». Autrement dit, la plupart d'entre eux testent l'ensemble du programme dans des requêtes presque réelles, vérifiant les réponses appropriées.

Dans certains cas, lorsque j'ai écrit des programmes pilotés par le réseau (principalement des protocoles spécifiques à une application), je n'avais pas de cadre de test complet à portée de main, ce qui me semblait facile pour le travail, j'ai donc fait la plupart des tests `` sur le réseau '', dans Bref, j'ai écrit un client très simple dans une autre langue avec un framework de test simple et commun, et la plupart des tests ont vérifié les réponses du serveur.

Pourtant, même dans ces cas, j'ai injecté quelques tests roulés à la main dans l'application réelle pour tester certaines parties hors réseau.

— Javier
source

0

Le cadre de test indépendant du langage est un cadre de test générique adapté au test d'acceptation (point de vue) et les cas de test dans ce cadre sont gérés par QA, par exemple Robotframework

— rrsguru
source

2

cela ne semble pas offrir quoi que ce soit de substantiel par rapport aux points soulevés et expliqués dans les 4 réponses précédentes

— gnat