¿Están utilizando las interfaces Soley para facilitar el troquelado y la burla en las pruebas unitarias ahora obsoletas?
En .NET, TypeMock Isolator y Microsoft Moles permiten aislar cualquier clase, propiedad o método, ya sea sellado, estático, protegido o no virtual. Entonces, lo que era imposible burlarse de Moq o Rhino Mocks, ahora ya no es el caso.
Siempre tuve cierta aversión con la idea de usar una interfaz simplemente para permitir la burla, cuando de otro modo solo existiría la clase concreta. No estoy solo en esta vista (veraquí, aquíyaquí) Más adelante se da a entender que los marcos de burla "modernos" ya no necesitan interfaces para probar o inyectar dependencias.
Sin embargo, aunque no puedo hablar por TypeMock Isolator, puedo decir que usar Mocks en Microsoft Moles es extremadamente lento. Tener un código como el siguiente en las pruebas unitarias hace que la velocidad de la prueba sea demasiado lenta para usarse con frecuencia:
MFile.ReadAllLinesString = (s) => csvDataCorrectlyFormatted;
MDirectoryInfo.AllInstances.GetFilesString = (di,fi) => fileInfoArray;
MFileInfo.AllInstances.NameGet = (fi) => "Doesn't Matter";
Estoy seguro de que si el método que se está probando se programó en una interfaz o clase base abstracta (para que el código del sistema de archivos se pueda abstraer en una especie de envoltorio), el uso de marcos como Moq para stubbing o burlas terminaría siendo más rápido . Pero luego volvemos a la situación de haber agregado complejidad de código de producción para básicamente la capacidad de realizar pruebas unitarias.
Me estoy inclinando a la opinión de que Isolator y Moles solo deben usarse cuando uno no puede burlarse de los marcos de burla tradicionales. Sin embargo, todavía lucho con la idea de haber agregado complejidad al código de producción por el simple hecho de probar.
Tengo curiosidad por lo que piensa el resto de la comunidad.
ACTUALIZACIÓN 10/06/10: Al decir que lucho con la noción de haber agregado complejidad de código de producción por el simple hecho de probar, me refiero a agregar una interfaz (o incluso una clase abstracta) cuando de lo contrario no es necesaria, como cuando se hace la clase concreta no sellado y métodos virtuales harían. Este último todavía permite costuras para la prueba. Incluso si luego uno encuentra la necesidad de usar una interfaz para múltiples implementaciones, ¿no podrían extraerlo de la clase? Pero a menos que surja esa necesidad, ¿por qué no seguirYAGNI.
Estoy totalmente de acuerdo con los principios SOLID donde hacen que la arquitectura de un programa sea más fácil de mantener. No creo que estos principios deban seguirse religiosamente en todos los casos. Creo que el mantra, "siempre depende", entra en juego muchas veces. De lo contrario, queda uno con cada tipo concreto que tenga una interfaz o clase base abstracta, incluso cuando solo haya una implementación.
Por último, no estoy diciendo que, debido a que Isolator and Moles le permite a uno evitar las limitaciones de aislamiento en marcos basados en proxy dinámico, no se debe diseñar una arquitectura que sea mantenible. En muchos casos, los principios SÓLIDOS son lo mejor y, por lo tanto, no se necesitarían aisladores o lunares. Son los casos en los que la interfaz se usa únicamente para pruebas que estoy cuestionando. También menciono otro punto secundario sobre la velocidad. Si uno elige usar Isolator y Moles, parece traer una penalización de velocidad. Así que ciertamente no creo que hagan obsoletos los marcos basados en proxy dinámico.