Devolución de listas vacías por defecto con Rhino Mocks

Question

Creo que es una buena práctica devolver siempre listas o matrices vacías en lugar de nulo cuando un método aparece sin resultados para evitar comprobaciones nulas en el código.

Dado que Rhino Mocks devuelve el valor predeterminado para un objeto, que es nulo para listas y matrices, muchas veces tengo que agregar las comprobaciones nulas o configurar las simulaciones con expectativas de devolver listas.

¿Hay alguna manera de configurar o extender Rhino Mocks con este comportamiento?

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

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

Answer 1

Resulta que este comportamiento es posible con Moq siempre que el objeto devuelto sea IEnumerable. Las siguientes pruebas pasan:

[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

No hay nada en Rhino Mocks que resuelva automáticamente su problema. La solución más simple es simplemente configurar un método de extensión/utilidad para cada tipo que use SetupResult (o repeat.any) para configurar un valor predeterminado.

Siempre podría ser difícil enumerar a través de los miembros, verificando ILists/Arrays y configurar los simuladores dinámicamente, esto depende de la cantidad de tipos que tenga y la cantidad de tipo que pueda dedicar a este método de utilidad.

¡Buena suerte!

Answer 3

Creo que cambiar el comportamiento predeterminado de los simuladores para devolver valores no predeterminados sería una jugada arriesgada.

¿Qué pasaría si sus implementaciones reales de ICustomerRepository tuvieran un error para que no devuelva una lista vacía y en su lugar devuelva un valor nulo?

Si escribió otras pruebas unitarias y las probó frente a versiones simuladas del ICustomerRepository que devolvió automáticamente la lista vacía, entonces pensaría que todo estaba bien. Incluso podría compilar ese código y pensar que funcionaría correctamente, por lo que ejecuta su aplicación compilada y comienza a fallar.

¿Por qué? Debido a que las clases que llegaron al ICustomerRepository no manejaron correctamente los valores nulos.

Prefiero ser explícito y establecer una expectativa en la prueba para devolver un IList vacío del método getCustomers() que tener algo "mágico" dentro del simulacro. ¿Por qué? Porque mejora la legibilidad, y el código funciona de acuerdo con lo que otros desarrolladores que podrían no estar tan familiarizados con Rhino esperarían que funcionara. es decir, un método sin expectativa devuelve el valor predeterminado.