¿Debo usar burlas en el código de producción?

Question

Tengo una situación en la que necesito simulacro algún código en producción. Esto es para hacer que una parte del código funcione en la mitad de la funcionalidad.

Tengo que elegir escribir clases vacías (para implementar la interfaz), o usar un sistema de simulación como moq.

Entonces, la pregunta es: ¿los sistemas de burla alcanzan el rendimiento o rompen la legibilidad del código de producción?

actualización
ejemplo:

interface IRocketSystem
{
   void LaunchTheRocket();
}

class SimulationRocketSystem:IRocketSystem
{
...
}

class RocketSystem:IRocketSystem
{
...
}

descubrí que tengo una clase de SimulationRocketSystem en producción, que es pequeña y no tengo mucho en el cuerpo. el sistema simulado tiene una línea de código ( nuevo Mock < IRocketSystem > (). Object ) para reemplazar clases como esta.

los pros para burlarse:
clases menos vacías en el proyecto.

Answer 1

Suena como un Objeto nulo . No creo en usar marcos burlones para esto por dos razones.

Primero, perjudica la legibilidad. Implementa la interfaz con una clase vacía con el nombre apropiado, luego documenta la intención dentro de esa clase. Por otro lado, si usa un marco de imitación, su documentación debe estar incrustada en el código en alguna parte. Además, será confuso ya que las personas tienden a esperar simulacros en el código de prueba y no entienden su intención de usar simulacros.

En segundo lugar, debe considerar qué sucede si alguien modifica la interfaz. ¿Qué pasa si se agrega un método? ¿Debería volver por defecto a nulo, como lo harían algunos marcos? ¿Qué sucede si el método debe devolver algún valor de retorno específico de acuerdo con el contrato de interfaz? Si tiene una implementación concreta, el compilador al menos lo protegerá un poco. Si usa un marco burlón, puede que no tenga suerte.

Answer 2

Un objeto simulado es algo que usa para probar, ya que le permitirá afirmar que se llamó correctamente. Me parece que lo que estás buscando es más como un trozo o un objeto proxy.

Dado que eventualmente implementará la clase en cuestión, tendría poco sentido tener un marco simulado que lo haga por usted. ¿Por qué no simplemente crear la clase e implementarla según sea necesario?

Answer 3

¿Qué tiene de malo una clase vacía?

De hecho, se reemplazará con una clase real, por lo que también puede comenzar con una clase real.

Creo que poner código simulado de cualquier tipo fuera es una mala política.

Answer 4

Lo llamas simulacro, pero parece que lo que estás haciendo es una separación adecuada de las preocupaciones.

Es bueno usar el polimorfismo sobre las declaraciones if para controlar lo que debería suceder.

Ejemplo, diga si desea que el registro sea opcional. El enfoque imperativo es proporcionar un boolean isLogging. Luego, cada vez verifique el booleano como if (isLogging) { ...logging code... }.

Pero si, en cambio, separa el código de registro real como una preocupación para otro objeto, puede establecer ese objeto en uno que haga lo que desee. Además de tener un registrador enrutado nulo que representa el registro deshabilitado y uno que realmente escribe en un archivo, también le permite suministrar un objeto de registro que escribe en una base de datos en lugar de un archivo, le permite agregar características al registrador, como como rotación de archivo de registro.

Es simplemente una buena programación orientada a objetos.

Answer 5

Tal vez sea un poco inusual, por lo que sería claro en mis comentarios, etc., que esta es una funcionalidad requerida. De lo contrario, ¡alguien estará muy confundido sobre cómo el código de prueba llegó a producción!

En cuanto al rendimiento, como siempre, debe medir esto ya que es muy específico. Sin embargo, me arriesgaría a adivinar que, dado que se está burlando de la funcionalidad que no ha escrito, bien podría ser mucho más rápido que su implementación rechazada. Eso es algo sobre lo que puede necesitar educar a sus usuarios, ya que cuando proporciona una implementación de funcionamiento final, bien podrían ver un impacto en el rendimiento :-)

La solución real es proporcionar una implementación ficticia a una interfaz existente y proporcionar la implementación real más adelante.

Answer 6

Realmente no sé sobre problemas de rendimiento. Pero en mi humilde opinión, debe tener mucho cuidado con la legibilidad. ¿No es mejor declarar una o más interfaces e implementarla de dos maneras diferentes?

--EDIT

La burla podría ser más fácil y usar menos líneas de código, pero aumenta la curva de aprendizaje de su código. Si llega un nuevo tipo y ve su código, necesitará más tiempo para comprenderlo. Personalmente, creo que es una característica aún no implementada del código. Pero si hubiera otra implementación de interfaz, o alguna otra buena decisión de diseño, & "; Lo obtendría &"; mucho más rápido y se sentiría más seguro al cambiar el código.

Bueno, esa es una opinión personal. Su código usará un patrón diferente al esperado. Es similar a & Quot; convención sobre configuración & Quot ;. Si no está utilizando la convención, debería tener más dificultades para configurarla (en su caso, documentar y dejar en claro lo que está haciendo).

Answer 7

Mi consejo: no lo pongas en producción. Nunca ponga en producción nada que pueda ralentizarlo, romperlo o causar que pierda su trabajo :)

Pero más importante de lo que creo es cuál es la política de su empresa y qué piensa su gerente. Nunca debe pensar en tomar una decisión como esta por su cuenta, se llama CYA.

Answer 8

  

Tengo que elegir escribir clases vacías o usar un sistema de burla como moq.

Envolverlo en un componente de fachada / adaptador dedicado y usar clases internas debería ser suficiente. Si sus clases vacías deben pasarse por el sistema, tiene un problema.