Comment puis-je tester les fonctions surchargées?

Question

J'ai donc une classe qui ressemble à ceci:

public class MyClass
{

    DatabaseDependency _depend;

    public MyClass(DatabaseDependency depend)
    {
        _depend = depend;
    }

    public string DoSomething(DBParameter database)
    {
        var result = _depend.GetResults(database, ...);
        string response = String.Empty;        

        // some logic to process the result 

        return response;
    }

}

Où DBParameter est une classe de valeurs simple contenant des propriétés telles que Server, DBName, DBType, etc.

Maintenant, je souhaite ajouter une surcharge à DoSomething afin qu’il accepte une chaîne de connexion au lieu du paramètre DBParameter (supposons que DatabaseDependency ait déjà une surcharge GetResults qui accepte une chaîne de connexion).

Ma question: plusieurs tests unitaires décrivent les différents chemins logiques utilisés pour traiter le résultat de DatabaseDependency.GetResults. Lorsque j'ajoute la surcharge à DoSomething, je refacturais le code pour que cette logique soit réutilisée par les deux surcharges (c'est-à-dire qu'elle passe probablement à une méthode privée). Quelle est la bonne façon de procéder pour tester l’unité? Dois-je avoir autant de tests unitaires pour vérifier tous les chemins logiques de la nouvelle surcharge que j'ajoute?

Answer 1

Si vous êtes sûr que votre méthode surchargée prenant une chaîne convertit uniquement en objet de connexion, puis en déléguant à l'original, vous devez ajouter une méthode de test supplémentaire.

Toutefois, cela s’arrête si vous refactorisez les méthodes surchargées sous-jacentes de sorte qu’aucune délégation n’ait lieu. Dans ce scénario, je me sentirais plus en confiance pour reproduire tous les tests des deux méthodes.

Je pense que le premier itinéraire est le plus pragmatique. Cependant, il est judicieux de lancer de temps en temps une analyse de la couverture de code, qui indiquera ultérieurement si d'autres tests sont nécessaires.

Answer 2

Si votre code reste tel qu'il est actuellement, alors oui: vous devrez également tester cette méthode à l'unité, en dupliquant essentiellement vos efforts de test.

Cependant, s'il est logique d'implémenter la fonctionnalité de sorte qu'une méthode appelle simplement l'autre, vous pouvez rendre cette méthode virtuelle. Cela vous permettrait de créer une sous-classe spécifique au test dans laquelle vous vérifieriez simplement que la méthode virtuelle est invoquée par l’autre méthode avec les valeurs correctes.

Une fois que cela a été vérifié par un ou plusieurs tests unitaires, vous n'avez plus besoin de tester cette méthode, car vous avez maintenant prouvé que la méthode appelle correctement l'autre méthode et vous pouvez concentrez vos efforts de test sur cette méthode.

Answer 3

Oui, refactorisez le traitement commun en méthode privée - je suppose que vous le feriez quand même, quelles que soient les considérations du test, le code en double est mauvais. Il est intéressant de voir comment penser aux tests nous conduit à faire ce qui est juste.

Ensuite, vous avez quelques tests simples pour chaque chemin d'initiation superposé.

Answer 4

Cela dépend si vous testez une boîte noire ou une boîte blanche et si votre application utilise les deux versions de la méthode.

Si vous supposez que vous ne faites que tester la mise en œuvre, il vous suffira de tester la version "principale". Si vous envisagez un rédacteur de test ne connaissant que l'API présentée (javadocs ou similaire), vous devez effectuer un test basé uniquement sur l'API, ce qui implique de tester complètement les deux méthodes.

Si votre application utilise une seule méthode, désapprouvez l'autre et créez un test conditionnel de version qui échoue lorsque la méthode dépréciée existe toujours selon une version prédéterminée. IE: indiquez que la méthode obsolète est supprimée à un moment donné.