¿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 la prueba de la unidad se rompe.

¿Es esto aceptable? ¿Debo 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 unitaria no sea tan frágil?

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

Answer 1

Sus pruebas deben garantizar que el código obedezca adecuadamente la regla de negocios. Por lo tanto, no escribiría pruebas que vayan en torno a la regla de negocios o dependerían del código de la regla de negocios en sí. En cambio, cuando cambia la regla de negocios, primero cambiaría la prueba para reflejar la nueva regla de negocios, luego, cuando mi código ya no pase la prueba, vaya y corríjala para que pase la prueba.

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

Tampoco desea que la prueba se acople a datos específicos. Digamos que al hacer un cálculo de impuestos, su prueba no debe redactarse para suponer que la clase bajo prueba usa el 5% como impuesto. En su lugar, debe escribir su prueba para que proporcione el porcentaje de impuestos y luego verifique que el cálculo se haya realizado correctamente. Presumiblemente, tendrá que probar un rango de valores para asegurarse de que también se capturen los valores fuera de rango. Un resultado de esto es que tendrá un mejor diseño, ya que le ayudará a evitar valores codificados y 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 la forma principal en que opera, mis pruebas unitarias se rompen. Esto es realmente esperado, ¡y bueno! Significa que puedo aislar cualquier ondulación inesperada en mi sistema y actualizar las pruebas para que coincidan con los cambios.

Si sus reglas son externas (algún tipo de lenguaje de secuencia de comandos o sproc de base de datos), deberá envolverlas en una prueba de integración y conectar sus pruebas de integración para la 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 ondulaciones inesperadas debido a un cambio en las reglas de negocios.

Answer 3

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.

Como se presentó, su pregunta parece que puede resolverse con el uso apropiado del patrón de Estrategia. La estrategia representa sus reglas de negocio, por lo que puede probarlas en un contexto puro sin preocuparse por el cliente.

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

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

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

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

Answer 4

Parece correcto que la prueba falle si se cambian las reglas, eso es de esperarse.

Puede facilitar el mantenimiento de la prueba en el futuro si usa un dispositivo de datos en lugar de valores codificados en la prueba misma. Por ejemplo, si su método debe devolver foo, puede tener eso en el accesorio. Cuando cambia la lógica de negocios, simplemente cambia el dispositivo y no tendrá que pasar por la prueba de la unidad.

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

Answer 5

Creo que es una pregunta incorrecta La regla de negocio y la prueba de unidad se encuentran en diferentes niveles de abstracción. La regla de negocio se encuentra 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, por lo que no puede usar la prueba unitaria para validar o verificar un negocio regla. Además, una regla comercial después del análisis y el diseño puede afectar varias unidades de códigos, por lo que nuevamente 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.