Cómo probar el código de unidad con muy pocas unidades

Question

¿Cómo puedo escribir pruebas de unidad para código existente y ya implementado que ha tenido una implementación de procedimiento en oposición a una implementación de OOP. Estamos utilizando Java/Spring, sin embargo, no hay muchos beans diferentes para las diferentes inquietudes, que se mezclan en una gran clase por cada pieza de funcionalidad principal. (Por ejemplo: tenemos clases/beans para cada trabajo por lotes, para nuestros DAO y algunos beans de tipo util y eso es todo).

Solo para dar más detalles, estas clases principales que deben probarse son aproximadamente 1k-2k líneas de código, y la única inyección de dependencia/OOP que usan es DAO y algunas utilidades extrañas. Tienen aproximadamente 1 método público que implementan para una interfaz que todos comparten.

Answer 1

Comience refactorizando. Los IDE modernos te permitirán refactorizar de forma segura sin romper o cambiar la semántica del código. Pero tienes que hacer esto conscientemente y ser inteligente.

Comience desde clases "externas" que no sean dependencias de ninguna otra clase.

El primer paso es extraer tantos métodos como sea posible. Normalmente, cuando encuentras un método enorme con muchas líneas en blanco/comentarios que separan bloques de código, son buenos candidatos para las extracciones. También se deben considerar bucles, condicionales anidados, long switch es, etc.

Una vez que tenga la plétora de bien llamados mire alrededor e intente agruparlos moviéndolos hacia arriba y hacia abajo. Si algún método está estrechamente relacionado y es lógicamente dependiente, extráigalos a una clase separada. IDE te ayudará.

Este proceso se puede repetir en cada capa y varias veces. Apunte a clases pequeñas y coherentes, si no puede nombrarlas (por ejemplo, debe usar "y" para expresar qué método/clase está haciendo), extraiga más.

Por supuesto que puede probarlo tal como está: supongo que se puede llegar a cada ruta de ejecución posible con un conjunto diferente de parámetros de entrada. Pero esto será una pesadilla para depurar.

Answer 2

Algunos indicadores en this enlace.

Si quiere ir más allá, considero que "Working effectively with legacy code" es una lectura obligatoria.

Answer 3

sólo para añadir algunas otras consideraciones a la gran respuesta por parte de Tomasz Nurkiewicz (que yo segundo por completo):

• veces (bueno, siempre es realmente), que es útil para escribir al menos un encapsular "prueba de aceptación "antes de comenzar la refactorización (si no existe). Una vez que pase, puede comenzar a refactorizar y asegurarse de no haber roto nada "importante" en cada paso. Antes de comenzar una importante tarea de refactorización, es muy útil tener dicho arnés para mantenerlo sano :)

• La refabricación no es solo una tarea técnica: no solo se quieren dividir grandes clases en clases más pequeñas y extraer código a los métodos. Desea pensar en lo que su código debe hacer, en términos de objetos, y pasar a un mejor diseño. Le hará la vida más fácil a largo plazo.

• Como regla general, trato de no tener ninguna clase por encima de 80-100 líneas de código (e idealmente menor que 50). Por supuesto que hay excepciones, pero cuando se hace más grande, suelo tratar de refactorizar preocupaciones separadas en objetos colaboradores que se inyectan en la clase principal.Mantiene el código legible y fácil de probar.