Créer un test JUnit pour une méthode couvrant toutes ses invocations dans l'espace de travail Eclipse

Question

Supposons la classe Java suivante :

class MyClass {
   public String methodA( String data, String expression ) {
      // expression is evaluated using data
      // ...
      // this leads to a result which is returned
      return result;
   }
}

Noter que expression est une instance d'un langage d'expression (DSL).Ainsi, l'évaluation de expression en utilisant data dépend de la combinaison des deux.Normalement, expression est une valeur fixe qui ne change pas souvent et data peut changer à travers toutes les invocations.

Eh bien, quelque temps plus tard, un bug est trouvé dans MyClass.methodA(String,String).Le bogue réside dans une classe sous-jacente et ne se produit que pour une combinaison spéciale de expression et data.Un test JUnit est facilement écrit pour ce cas particulier et peut être corrigé.

Malheureusement, cette méthode est fréquemment utilisée dans l’ensemble du projet.La hiérarchie des appels Eclipse identifie plus de 97 autres méthodes dans lesquelles cette méthode est utilisée.J'ai maintenant peur de la régression, si j'applique simplement le correctif.Pour me sentir plus en sécurité, j'aimerais faire des tests de régression.

Normalement, les tests unitaires doivent prendre en compte tous les types d'invocations importants, en particulier les cas limites.Mais, comme expression est un DSL qui peut varier considérablement, il n'est pas facile de tester toutes les utilisations potentielles.De plus, ces tests n’identifieraient pas les fausses utilisations basées sur le bogue.

Mon idée est donc de procéder de la manière suivante :

1. Recherchez toutes les invocations de cette méthode (comme l'utilisation de la "hiérarchie des appels" dans Eclipse) et extrayez toutes les valeurs de expression.

2. Échantillonnez suffisamment de valeurs réelles pour data (par exemple.de la base de données) et évaluez toutes les expressions dès la première étape en utilisant la version originale de MyClass.methodA(String,String).Sauvez les triples (data, expression, result) à un fichier.

3. Implémentez la correction de bugs.

4. Méthode d'essai MyClass.methodA(String,String) en utilisant le fichier ci-dessus pour affirmer que les résultats n'ont pas changé.

Questions suivantes:

Que pensez-vous de cette approche?

En utilisant la hiérarchie des appels dans Eclipse, je ne peux copier et coller que les méthodes appelantes mais pas l'invocation exacte, y compris les arguments, dans le presse-papiers (cf.étape 1).Je devrais copier l’appel appelant à la main pour chaque méthode trouvée.Comment extraire les invocations de manière pratique (dans l'espace de travail complet d'Eclipse, donc dans plusieurs projets) ?

À mon humble avis, je ne teste qu'une seule méthode, les tests ne couvrent donc qu'une seule unité.Est-il possible d'utiliser JUnit pour l'étape 4 ou existe-t-il quelque chose de plus sophistiqué ?

Answer 1

Étant donné que la valeur supplémentaire attendue en testant votre logiciel est de couvrir le plus grand nombre de circonstances avec les coûts les plus bas et un résultat maximum, je serais d'accord avec votre approche.

Collecter des exemples de valeurs réelles à partir de votre logiciel et les enregistrer dans un fichier représentatif ne devrait pas être si complexe à réaliser et me semble être le meilleur moyen d'analyser cette chose.Même si vous devez le copier manuellement.