2010-06-04 11 views
21

Tengo un conjunto tal de Constructores:¿Utiliza Moq para simulacro de Constructor?

public BusinessObjectContext() 
     : this(CloudStorageAccount.FromConfigurationSetting("DataConnectionString").TableEndpoint.ToString(), 
       CloudStorageAccount.FromConfigurationSetting("DataConnectionString").Credentials) {} 

public BusinessObjectContext(string dataConnectionString) 
     : this(CloudStorageAccount.Parse(dataConnectionString).TableEndpoint.ToString(), 
       CloudStorageAccount.Parse(dataConnectionString).Credentials) { } 

public BusinessObjectContext(String baseAddress, StorageCredentials credentials) 
     : base(baseAddress, credentials) { } 

Sin embargo, cuando las pruebas/Burlándose necesito el objeto sin que ninguno de los parámetros de cadena de conexión. ¿Cómo puedo hacer esto, preferiblemente en Moq?

¿Es esto posible en absoluto?

Respuesta

17

Parece que tiene un olor a código: constructor is doing too much work. El artículo incluye un conjunto de soluciones para dichos escenarios. Básicamente la respuesta es solo realizar asignaciones en constructores, no ejecutar lógica de negocios.

+0

Hrrm. Veo el argumento en este concepto. Por otro lado, quería proteger al usuario del objeto GenericBusinessObject de pensar en el contexto del origen de datos. Si sigo sus argumentos, el usuario de GenericBusinessObject tiene que pensar en ello. Esto es menos abtraction. Quizás no haya otra manera, pero algo me hace dudar. –

+1

Haga una fábrica o use un Conatainer de IOC para eliminar esta necesidad de que el usuario se preocupe por el contexto de los datos. – Finglas

26
var myMockBOC = new Mock<BusinessObjectContext>(null, null); 

Esto pasará los nulos para sus dos parámetros.

Otro enfoque sería crear un constructor interno para uso de prueba solamente, y usar InternalsVisibleTo para permitir que su ensamblaje de prueba lo use. Desafortunadamente, esto tiene un gran inconveniente porque si firma sus ensamblajes, Moq is unable to use the constructor. Sin embargo, se supone que esto debe abordarse en la versión 4.0 de Moq.

+6

El inconveniente de un constructor interno es que ahora está escribiendo código para respaldar las pruebas de su unidad. –

+2

Yo diría que eso es aceptable cuando existe un requisito determinado de que la API * pública * no sea inyectable. La única vez que presentaría problemas sería si sus constructores no fueran simplistas y tuvieran lógica de negocios; entonces, como dice el refrán, usted tendría dos problemas ... – womp

+0

¡Solución muy simple! ¡Me ayudo mucho! –

Cuestiones relacionadas