¿Cómo probar las reglas comerciales de la unidad?

Question

Necesito una prueba de unidad para asegurarme de que estoy acumulando las horas de vacaciones correctamente. Pero las horas de vacaciones se acumulan de acuerdo con una regla de negocios, si la regla cambia, entonces se rompe la prueba de la unidad.

¿Esto es aceptable? ¿Debería exponer la regla a través de un método y luego llamar a ese método desde mi código y mi prueba para asegurarme de que la prueba de la unidad no sea tan frágil?

Mi pregunta es: ¿Cuál es la forma correcta de probar las reglas comerciales de la unidad que pueden cambiar?

Answer 1

Sus pruebas deben garantizar que el código obedezca correctamente la regla de negocio. Por lo tanto, no escribiría pruebas que rodeen la regla de negocio o confíe en el código de la regla de negocio en sí. Por el contrario, cuando la regla de negocios cambie, primero cambiaría la prueba para reflejar la nueva regla comercial, luego, cuando mi código ya no pase la prueba, vaya y corrija el código para que pase la prueba.

Lo que no quiere que suceda es escribir su prueba para que cuando cambie cómo se aplica la misma regla de negocios, se rompa la prueba. Es más fácil decirlo que hacerlo, pero esencialmente lo que quiere probar es el mínimo requerido para implementar la regla sin dictar muy estrictamente cómo se implementa el código. Si el resultado de la regla es diferente, sin embargo, primero debe cambiar la prueba y luego el código para que coincida.

Además, tampoco desea que la prueba se acople a datos específicos. Digamos que al hacer un cálculo de impuestos, su prueba no debe escribirse para suponer que la clase bajo prueba usa el 5% como el impuesto. En su lugar, debe escribir su prueba para que proporcione el porcentaje del impuesto y luego verifique que el cálculo se haya realizado correctamente. Presumiblemente, tendrá que probar un rango de valores para asegurarse de que los valores fuera de rango también sean capturados. Un resultado de esto es que tendrá un mejor diseño ya que esto le ayudará a evitar valores codificados y a hacer que su código de producción sea más flexible a los cambios en los datos.

Answer 2

Tengo una configuración similar; sin embargo, mis reglas comerciales están compiladas pero tienen opciones configurables (las suyas pueden diferir). Cuando una regla de negocios cambia una forma central en la que opera, mi unidad de prueba se rompe. Esto es realmente esperado, ¡y bueno! Significa que puedo aislar cualquier ondulación inesperada en todo mi sistema y actualizar las pruebas para que coincidan con los cambios.

Si sus reglas son externas (algún tipo de script language o sproc de base de datos) entonces deberá envolverlos en una prueba de integración y cablear sus pruebas de integración para una ejecución automatizada. Si bien ya no es una prueba unitaria, las pruebas de integración también son bastante importantes y lo ayudarán de la misma manera que las pruebas unitarias para evitar las fluctuaciones inesperadas debido a un cambio en las reglas comerciales.

Answer 3

Parece correcto que la prueba falla si se cambian las reglas, eso es de esperar.

Puede facilitar el mantenimiento de la prueba en el futuro si utiliza un dispositivo de datos en lugar de valores codificados en la prueba en sí. Por ejemplo, si su método debe regresar a foo, puede tenerlo en el dispositivo. Cuando cambie la lógica comercial, simplemente cambie el dispositivo y no tendrá que pasar por la prueba unitaria.

Por supuesto, esto depende en gran medida del tipo de lógica que está probando, y puede no ser siempre aplicable.

Answer 4

Parece que tiene reglas comerciales, y luego tiene clientes de esas reglas comerciales. Si esos dos pueden variar de forma independiente, sería aconsejable diseñar su API en consecuencia.

Tal como se presentó, su pregunta parece que se puede resolver con el uso adecuado del patrón de Estrategia.La estrategia representa las reglas de su negocio, por lo que puede probarlas en un contexto puro sin preocuparse por el cliente.

Cuando la regla comercial cambia, puede tener más sentido simplemente dejar la antigua Estrategia tal como está (en caso de que la necesite más adelante), y escribir (y probar la unidad) una Estrategia completamente nueva que represente la nueva empresa regla.

Cuando haya terminado completamente con la nueva Estrategia, puede reemplazar la Estrategia en el cliente.

Al probar la unidad del cliente, debe hacerlo contra una estrategia de prueba doble (como un simulacro) para verificar que el cliente interactúa correctamente con la estrategia sin depender de ninguna implementación de estrategia en particular.

De esta forma, obtiene una separación clara de las preocupaciones y mantiene las pruebas de la unidad mantenibles. También obedeces el principio abierto/cerrado.

Answer 5

Creo que es una pregunta incorrecta Business Rule y la prueba de unidad se encuentran en diferentes niveles de abstracción. La regla empresarial está en el nivel superior de abstracción (Business Modeling) pero la prueba unitaria es para probar una unidad de código que está en el nivel más bajo de abstracción así que no puede usar la prueba unitaria para validar o verificar una regla comercial. Además, una regla comercial después del análisis y el diseño puede afectar a varias unidades de códigos, así que de nuevo no puede usar la prueba unitaria para validar o verificar una regla comercial. Creo que puede usar el caso de prueba o el Escenario BDD para validar y verificar una regla comercial.