En mi humilde opinión, Rhino Mocks produce un mensaje de diagnóstico poco claro cuando se utiliza AssertWasCalled para verificar que se ha llamado un método con un argumento específico.Rhino Mocks - AssertWasCalled: Cómo mejorar el mensaje de diagnóstico no claro cuando los argumentos incorrectos
Ejemplo:
interface ISomeInterface
{
void Write(string s);
}
[TestFixture]
public class SomeTests
{
[Test]
public void WriteShouldBeCalledWithCorrectArguments()
{
// Arrange
var mock = MockRepository.GenerateMock<ISomeInterface>();
var sut = new SomeClass(mock);
// Act
sut.DoSomething();
// Assert
mock.AssertWasCalled(x => x.Write(Arg<string>.Is.Equal("hello")));
}
}
Ahora, si la prueba falla con este mensaje ...
Rhino.Mocks.Exceptions.ExpectationViolationException: ISomeInterface.Write (igual a hola); Número esperado 1, real # 0.
... no se puede saber si se produce un error porque
A. 'Escribir' Nunca se invoca -o-
B. 'Escribir' es, de hecho, invocado pero con el argumento incorrecto
Si B sería la causa de la falla, entonces sería mucho más claro si el mensaje se leería algo como esto:
Rhino.Mocks.Exceptions.ExpectationViolationException: ISomeInterface.Write (arg cadena): el método se llama, pero con los argumentos incorrectos ts: esperado: hola, real: bye
¿Puedo solucionar este inconveniente por mi cuenta (escribiendo correspondencias personalizadas para Rhino de alguna manera) o simplemente tengo que escribir un simulacro manual para esto?
Considere probar Moq y/o hacer pruebas basadas en estado. http://code.google.com/p/moq/ – TrueWill
Desafortunadamente, Moq tiene el mismo problema. – Chris