¿El propósito de crear tipos anónimos en AutoFixture para la clase bajo prueba?

Question

Recientemente comencé a usar la biblioteca AutoFixture (http://autofixture.codeplex.com/) para Pruebas unitarias y me gusta bastante.

Recibí este ejemplo de código del sitio web de AutoFixture CodePlex. Mi pregunta es en cuanto a número de línea 8.

1. [TestMethod] 
2. public void IntroductoryTest() 
3. { 
4.  // Fixture setup 
5.  Fixture fixture = new Fixture(); 
6. 
7.  int expectedNumber = fixture.CreateAnonymous<int>(); 
8.  MyClass sut = fixture.CreateAnonymous<MyClass>(); 
9.   
10.  // Exercise system 
11.  int result = sut.Echo(expectedNumber); 
12.   
13.  // Verify outcome 
14.  Assert.AreEqual<int>(expectedNumber, result, "Echo"); 
15.  // Teardown 
16. } 

que no puedo entender, ¿por qué tenemos que crear un objeto anónimo de la clase que se está probando.

 MyClass sut = fixture.CreateAnonymous<MyClass>(); 

La clase debería ser el objeto real IMO. Para un ejemplo ...

 var sut = new MyClass();  

Mi pregunta es, ¿cuál es el beneficio real de crear un objeto anónimo contra el cual evaluar?

Answer 1

En el caso trivial, tiene razón: no hay diferencia de material.

Sin embargo, SUT API Encapsulation tiene sus usos - como su sistema bajo prueba y sus Fixture Object s obtener más interesante que algo con un ctor predeterminado, por ejemplo:

• (¿realmente tiene no hay dependencias?) MyClass requiere cosas para ser alimentado en ello de constructores
• `MiClase ha leído propiedades de lectura/escritura que no desea que los valores por defecto para aplicar a (programación por coincidencia)
• el constructor de MyClass tiene nada eL se desea apply a policy to

Entonces el poder de tener un Sut Factory inicia involucradas que entran en juego, dejando caer código extraño de distancia y que le permite aplicar conceptos transversales al proceso.

EDIT: Por alguna razón @Brad Wilson saw fit to repost this article que es un poco saliente