Renvoyer les listes vides par défaut avec Rhino Mocks

Question

Je pense que c'est une bonne habitude de toujours retourner des listes vides ou des tableaux au lieu de null lorsqu'une méthode arrive sans résultat pour éviter les vérifications nuls dans le code. Étant donné que Rhino Mocks renvoie la valeur par défaut d'un objet, qui est null pour les listes et les tableaux, plusieurs fois je dois soit rajouter les vérifications nuls, soit paramétrer les attentes avec des retours de listes.

Existe-t-il un moyen de configurer ou d'étendre Rhino Mocks avec ce comportement?

var repositoryMock = MockRepository.GenerateMock<ICustomerRepository>(); 
IList<Customer> customers = repositoryMock.getCustomers(); 

Assert.IsNotNull(customers); 
Assert.AreEqual(0, customers.Count); 

Answer 1

Il s'avère que ce comportement est possible avec Moq tant que l'objet renvoyé est IEnumerable. Les tests suivants passent:

[Test] 
public void EmptylListTest() 
{ 
    var repositoryMock = new Mock<ICustomerRepository>(); 

    IEnumerable<Customer> customers = repositoryMock.Object.GetCustomers(); 

    Assert.IsNotNull(customers); 
    Assert.AreEqual(0, customers.Count()); 
} 

[Test] 
public void EmptyArrayTest() 
{ 
    var repositoryMock = new Mock<ICustomerRepository>(); 

    Customer[] customerArray = repositoryMock.Object.GetCustomerArray(); 

    Assert.IsNotNull(customerArray); 
    Assert.AreEqual(0, customerArray.Length); 
} 

public interface ICustomerRepository 
{ 
    IEnumerable<Customer> GetCustomers(); 
    Customer[] GetCustomerArray(); 
} 

Answer 2

Il n'y a rien dans Rhino Mocks pour résoudre automatiquement votre problème. La solution la plus simple consiste simplement à configurer une méthode d'extension/utilitaire pour chaque type qui utilise SetupResult (ou repeat.any) pour configurer une valeur par défaut. Vous pouvez toujours être difficile et énumérer les membres, en vérifiant ILists/Arrays et en configurant les mocks dynamiquement - cela dépend du nombre de types que vous avez et du type que vous pouvez dédier à cette méthode utilitaire.

Bonne chance!

Answer 3

Je pense que changer le comportement par défaut des répliques pour retourner des valeurs non-par défaut serait un mouvement risqué. Que se passerait-il si vos implémentations réelles de ICustomerRepository contenaient un bogue de sorte qu'il ne renvoie pas une liste vide et renvoie une valeur null?

Si vous avez écrit d'autres tests unitaires et testé par rapport à une version fictive de ICustomerRepository qui a automatiquement renvoyé la liste vide, alors vous penseriez que tout était OK. Vous pourriez même construire ce code et penser qu'il fonctionnerait correctement, donc vous exécutez votre application compilée et elle commence à s'écraser.

Pourquoi? Parce que vos classes qui ont frappé ICustomerRepository n'ont pas géré correctement les valeurs null. Je préférerais être plus explicite et définir une attente dans le test pour renvoyer un IList vide de la méthode getCustomers() plutôt que d'avoir quelque chose de "magique" à l'intérieur du mock. Pourquoi? Parce qu'il améliore la lisibilité, et que le code fonctionne en fonction de ce que d'autres développeurs qui ne sont pas familiers avec rhino s'attendent à ce que cela fonctionne. c'est-à-dire qu'une méthode sans attente renvoie la valeur par défaut.