Mocking .nettiers DataRepository appels

Question

J'ai un projet dans lequel j'utilise du code généré par .nettiers comme DAL.

Pour le moment, mes tests consistent à configurer physiquement les données de test dans la base de données pour chaque test, puis à permettre aux objets nettiers d'atteindre la base de données et de revenir si nécessaire.

De toute évidence, ce n'est pas particulièrement efficace et jusqu'à présent, mes 250 tests impairs prennent environ 10 minutes à s'exécuter, j'ai donc cherché à ajouter des moqueries dans mes tests.

Bien que je sois à peu près sûr de comprendre les concepts de simulation des appels à la base de données, j'ai du mal à l'appliquer aux nettiers en particulier, car il est assez fortement couplé à la base de données.

L'une des méthodes que je souhaite tester ressemble à ceci (réduisez légèrement par souci de brièveté):

public class InterfaceManagerService
{
    public DataDocument SaveDataDocument(DataDocument entity)
    {
        var lookupEntity = DataRepository.DataDocumentProvider.GetByDocumentId(entity.DocumentId);
        if (lookupEntity == null)
        {
            File fileEntity = new File();
            fileEntity.Name = entity.Name;

            var savedFileEntity = DataRepository.FileProvider.Save(fileEntity);

            entity.FileId = savedFileEntity.FileId;

            var savedEntity = DataRepository.DataDocumentProvider.Save(entity);

            return (savedEntity);
        }             
    }
}

Actuellement, j'utilise une version d'essai de Typemock, car cela semble faire ce qui est requis, mais je suis ouvert à toutes les alternatives, en particulier celles open source.

Le premier problème que je rencontre est de savoir si je devrais créer une instance simulée de InterfaceManagerService, ou du DataRepository, ou des entités elles-mêmes (les entités nettiers ont une interface qui pourrait être utile).

Le deuxième problème est de savoir comment créer le faux objet qui doit être retourné, car les nettiers mettent un tas de propriétés supplémentaires dans les entités qui entraîneraient des tests volumineux et peu maniables si je crée une fausse instance de chaque objet I ' Je m'attends.

Je suppose qu'en fin de compte, je cherche une direction dans la meilleure façon d'écrire des tests unitaires pour les méthodes qui utilisent les méthodes de référentiel de données nettiers, mais pour éviter de frapper la base de données, car il ne semble pas y avoir grand-chose à ce sujet sur Internet actuellement.

Answer 1

Je vais faire quelques suggestions tirées de mon expérience personnelle. Bien que celles-ci ne répondent pas à toutes vos préoccupations, j'espère qu'elles vous seront au moins utiles.

• Rhino Mocks est un framework de moquerie assez connu. Si vous cherchez une alternative à Typemock, je vous le suggère.

• Quant à savoir s'il faut se moquer de l'InterfaceManagerService ou du DataRepository, je dirais que cela dépend de ce que vous essayez de tester. Voulez-vous tester InterfaceManagerService? Ensuite, vous souhaiterez créer des objets fictifs pour DataRepository.FileProvider et DataRepository.DataDocumentProvider. Si vous n'êtes pas déjà familier avec le concept d '«injection de dépendances», alors regardez-le; il semble que vous devriez appliquer une injection de dépendances à votre classe InterfaceManagerService (en supposant que vous vouliez le tester unitaire).

  Si vous souhaitez tester un code qui consomme le InterfaceManagerService, alors simulez-vous simplement le InterfaceManagerService.

... comment créer le faux objet à renvoyer, puisque nettiers met un tas de propriétés supplémentaires dans les entités qui en résulteraient dans des tests volumineux et peu maniables si je crée une fausse instance de chaque objet que j'attends.

• Écrire un seul test unitaire est facile. Il est difficile d'écrire de nombreux tests unitaires pour couvrir tous les scénarios que vous devez couvrir, et ce d'une manière efficace qui n'entraîne pas la duplication de beaucoup de code tout au long de vos tests unitaires, en particulier lorsque les entrées et les sorties de la méthode testée sont complexes.

  Pour cela, je n'ai pas beaucoup de conseils, sauf pour dire que mon approche personnelle est d'essayer de consolider la logique d'initialisation des tests et la logique de vérification des tests afin d'éviter beaucoup de duplication de code, mais en même temps j'essaye pour éviter de rendre le code de test unitaire lui-même si compliqué qu'il devienne difficile à comprendre et sujet à des bogues.

  En général, je pense que je finis par diviser la logique de test en 3 catégories: entrées / initialisation, attentes et résultats / vérification. J'ai trouvé que mettre la logique dans ces 3 catégories m'a été utile pour pouvoir consolider le code commun à travers les tests unitaires.

  Les tenants du développement axé sur les tests diraient probablement que lutter pour produire un ensemble propre de code de test unitaire est une indication d'un défaut de conception dans l'application. Je ne vais pas être en désaccord avec cela, mais je dirai que, malheureusement, les projets auxquels j'ai participé n'ont généralement pas produit une base de code de test unitaire à la fois simple et complète. Les tests unitaires simples n'exploraient généralement pas vraiment les scénarios problématiques, et les tests unitaires complets nécessitaient généralement beaucoup de logique de configuration de test.

Answer 2

J'utilise TypeMock et je l'aime beaucoup.Il est vraiment facile de se moquer des éléments internes d'une classe.Ce que je cherche à faire est de remplacer la classe DataRepository et de faire en sorte que TypeMock renvoie un jeu de résultats attendu à mon composant qui le consomme, pour m'assurer que ce composant fonctionne comme prévu.

Mais en réalité, cela dépend de ce que vous testez.Si vous testez le service, simulez le référentiel de données et renvoyez les résultats attendus.Si vous testez le référentiel, simulez les éléments internes consommés par le référentiel.Donc, une bonne idée est de simuler les références externes au composant que vous testez, à mon humble avis.

HTH.