Restituire gli elenchi vuoti come predefiniti con Rhino Mazzi

Question

Penso che sia una buona pratica restituire sempre liste o matrici vuote invece di null quando un metodo non produce risultati per evitare i controlli nulli nel codice.

Poiché Rhino Mocks restituisce il valore predefinito per un oggetto, che è nullo per elenchi e matrici, molte volte devo aggiungere nuovamente i controlli Null o configurare i mock con aspettative per restituire elenchi.

C'è un modo per configurare o estendere Rhino Mock con questo comportamento?

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

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

Answer 1

Si scopre che questo comportamento è possibile con finché l'oggetto restituito è IEnumerable. I seguenti test passano:

[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

Non c'è nulla in Rhino Mocks per risolvere automaticamente il problema. La soluzione più semplice consiste semplicemente nell'impostare un metodo extention/utility per ciascun tipo che utilizza SetupResult (o repeat.any) per configurare un valore predefinito.

È sempre possibile ingannare e enumerare i membri, controllare gli ILists/Array e configurare i mock in modo dinamico, a seconda del numero di tipi che si hanno e del tipo che si può dedicare a questo metodo di utilità.

Buona fortuna!

Answer 3

Penso che cambiare il comportamento predefinito dei mock per restituire valori non predefiniti sarebbe una mossa rischiosa.

Che cosa succederebbe se le reali implementazioni di ICustomerRepository avessero un bug in esso in modo che non restituisse una lista vuota e invece restituisse un null?

Se hai scritto altri test di unità e testato su una versione fittizia di ICustomerRepository che restituiva automaticamente la lista vuota, allora penseresti che tutto fosse OK. Potresti anche creare quel codice e pensare che funzioni correttamente, quindi esegui la tua app compilata e inizia a bloccarsi.

Perché? Perché le classi che hanno colpito l'ICustomerRepository non gestiscono correttamente i null.

Preferisco essere piuttosto esplicito e impostare un'aspettativa nel test per restituire un IList vuoto dal metodo getCustomers() piuttosto che avere qualcosa di "magico" all'interno della simulazione. Perché? Perché migliora la leggibilità e il codice funziona in base a ciò che altri sviluppatori che potrebbero non essere così familiari con il rinoceronte si aspettano che funzioni. Ad esempio, un metodo senza un'aspettativa restituisce il valore predefinito.