Un code de test unitaire qui fait essentiellement de la persistance - Dois-je m'en préoccuper?

Question

J'utilise une API qui interagit avec un DB. Cette API a des méthodes pour interroger, charger et enregistrer des éléments dans la base de données. J'ai écrit des tests d'intégration qui font des choses comme créer une nouvelle instance, puis vérifier que lorsque je fais une requête pour cette instance, l'instance correcte est trouvée. Tout va bien. Je voudrais avoir des tests unitaires plus rapides pour ce code, mais je m'interroge sur l'utilité de n'importe quel test unitaire et s'ils me donnent quelque chose. par exemple, disons que j'ai une classe pour sauvegarder un élément que j'ai via l'API. C'est le code de psuedo, mais je comprends l'utilisation de l'API que j'utilise.

public class ElementSaver 
{ 
    private ITheApi m_api; 

    public bool SaveElement(IElement newElement, IElement linkedElement) 
    { 
     IntPtr elemPtr = m_api.CreateNewElement() 
     if (elemPtr==IntPtr.Zero) 
     { 
      return false; 
     } 
     if (m_api.SetElementAttribute(elemPtr,newElement.AttributeName,newElement.AttributeValue)==false) 
     { 
      return false; 
     } 
     if (m_api.SaveElement(elemPtr)==false) 
     { 
      return false; 
     } 

     IntPtr linkedElemPtr = m_api.GetElementById(linkedElement.Id) 
     if (linkedElemPtr==IntPtr.Zero) 
     { 
      return false; 
     } 
     if (m_api.LinkElements(elemPtr,linkedElemPtr)==false) 
     { 
      return false; 
     } 
     return true; 

    } 
} 

est-il des tests d'une valeur de l'unité d'écriture qui raillent le membre de m_api? il semble que je peux tester que si l'un des différents appels échoue, que false est retourné, et que si tous les différents appels réussissent que true est retourné, et je pourrais définir des attentes que les différentes méthodes sont appelées avec les paramètres attendus, mais Est-ce utile? Si je devais refactoriser ce code de sorte qu'il utilisait des méthodes légèrement différentes de l'API, mais atteignait le même résultat, cela briserait mes tests et j'aurais besoin de les changer. Cette fragilité ne semble pas très utile.

Dois-je m'embêter avec des tests unitaires pour un code comme celui-ci, ou devrais-je m'en tenir aux tests d'intégration que j'ai?

Answer 1

Regardez à quoi ressemblent les tests. Si vous ne faites que tester si des données arrivent dans la base de données, etc. Vous faites probablement la bonne chose en faisant seulement des tests d'intégration automatisés. S'il y a une logique que vous voulez tester, alors vous pouvez vouloir voir si vous pouvez factoriser votre logique dans des classes séparées que vous pouvez tester et façades autour du code de l'infrastructure qui ne contiennent aucune logique.

Answer 2

Il est une bonne idée de se moquer des m_api dans mon code pour les raisons suivantes (dont tous ne s'appliquent à votre exemple pseudo-code):

• Comme vous l'avez mentionné, vous pouvez vérifier que votre classe effectue le traitement des erreurs correctement
• Dans les cas où vous avez un code plus complexe dans votre classe (par exemple, la mise en cache), vous pouvez utiliser les attentes sur votre maquette pour vous assurer que la classe se comporte correctement. Par exemple, récupérez deux fois le même objet mais assurez-vous que m_api n'est appelé qu'une seule fois.
• Votre test unitaire peut tester le comportement sans créer de jeu de données approprié. Cela augmente la maintenabilité dans le temps lorsque le modèle de données sous m_api change.