2009-12-03 4 views
3

Je travaille sur l'écriture de tests unitaires correctement, et je me demande si c'est une mauvaise technique de tester le résultat d'une méthode testée en appelant une autre méthode pour vérifier le résultat ?Tests unitaires: Utiliser une autre méthode pour vérifier que la méthode testée fonctionne correctement

ie. Dans l'exemple ci-dessous, je peux seulement vérifier qu'un appel de méthode StoreObject a réussi (c'est-à-dire un objet stocké dans le cache) en appelant FetchObject ou la propriété HasCachedObjects, les deux contenant une logique qui doit être testée séparément. Que feriez-vous dans ce cas où le résultat est caché de l'API publique?

J'ai une classe de cache:

public class Cache { 

    private Dictionary<string, object> _Cache = null; 

    public bool HasCachedObjects { 
    get { 
     if (_Cache.Count > 0) { 
     return true; 
     } else { 
     return false; 
     } 
    } 
    } 

    public Cache() { 
    _Cache = new Dictionary<string,object>(); 
    } 

    public void StoreObject(string key, object obj) { 
    _Cache[key] = obj; 
    } 

    public object FetchObject(string key) { 
    if (_Cache.ContainsKey(key)) { 
     return _Cache[key]; 
    } 

    return null; 
    } 
} 
+0

peut vous aussi poster votre test? –

+0

sa classe simple imaginaire, serait appel cache.StoreObject ("test", obj); puis Assert.AreEqual (true, cache.HasCachedObjects); ou quelque chose comme ça – theringostarrs

Répondre

3

Ne pensez pas d'un cas d'essai tester une méthode; Pensez-y comme testant une unité de fonctionnalité (ou peut-être un cas d'utilisation).

Votre test peut donc être StoreObject_WhenSuccessful_AddsToCache ou un tel.

Et oui, je confirmerais le test via l'API publique.

2

Pas du tout. En fait, il s'agit probablement de deux tests différents - l'un pour vérifier que HasCachedObjects est vrai après la mise en cache d'un objet et l'autre pour vérifier que vous pouvez récupérer un objet après l'avoir stocké.

(je ne suis pas vraiment sûr de ce que cette classe ne sauf envelopper un dictionnaire dans une API légèrement différente, mais c'est un autre sujet ...)

+0

C'est un exemple de classe très simplifié pour la question ... et comment est-ce un «sujet»? – theringostarrs

+0

Parce que la classe ne semble pas avoir beaucoup de valeur, il est difficile de vraiment comprendre comment le tester. En général, j'évite les tests basés sur l'état, mais c'est vraiment la seule chose que vous pouvez faire avec le design présenté. J'utilise habituellement TDD et les tests unitaires pour spécifier les exigences du comportement de la classe, puis écrire le code pour correspondre à cela ... dans ce cas, on ne sait pas ce que la classe est en train de faire, ou est censé faire, alors comment pour tester il est également peu clair. – kyoryu

+0

Mais pour ajouter à ce que dit TrueWill, je suis d'accord - ne pensez pas à un test comme testant une méthode spécifique, pensez-y comme testant un comportement particulier d'une classe. Une méthode peut être invoquée par plus d'un test, et un test peut invoquer plus d'une méthode ... – kyoryu

0

Au lieu de tester différentes méthodes que vous pouvez tester différents cas d'utilisation/scénarios, par exemple: ajouter à cache - l'objet est là, etc ...

Questions connexes