No hay una receta general, pero algunas reglas generales ( suponiendo un lenguaje estáticamente tipado pero que realmente no debería importar):
1) Echa un vistazo a la firma del método. Se da a conocer lo que pasa en y es de esperar que viene a cabo . Desde el estado general de esta clase de dios , supongo que este es un primer punto de dolor . Supongo que se usa más de un parámetro.
2) Utilice la función de búsqueda de su editor / EDI para determinar Exit-Points (por lo general un retorno se utiliza statement_)
De lo que sabe, qué necesita la función para las pruebas y qué espera a cambio .
Entonces, una primera prueba simple sería llamar a la función con los parámetros necesarios y esperar que el resultado no sea nulo . Eso no es mucho, pero es un punto de partida.
A partir de eso, podría entrar en un círculo hermenéutico (un término acuñado por HG Gadamer, un filósofo alemán). El punto es: ahora tiene una comprensión rudimentaria de la clase y actualiza esta comprensión con nuevos conocimientos detallados y tiene una nueva comprensión de toda la clase.
Esto combinado con el método científico : hacer suposiciones y ver si se cumplen.
3) Tome un parámetro y mire, en qué parte de la clase se transforma de alguna manera:
Por ejemplo, estás haciendo Java como yo, por lo general hay getter y setter que puedes buscar. SearchPattern $objectname. (o $objectname\.(get|set)si estás haciendo Java)
Ahora podría hacer más suposiciones sobre lo que hace el método.
Rastree solo los parámetros de entrada ( primero ) cada uno a través del método. Si es necesario, haga algunos diagramas o tablas , donde escriba cada cambio en cada una de las variables.
A partir de eso, puede escribir más pruebas, describiendo el comportamiento del método. Si tiene una comprensión aproximada de cómo se transforma cada parámetro de entrada a lo largo del método, comience a experimentar : pase nulo para un parámetro o entrada extraña . Haga suposiciones, verifique el resultado y varíe los aportes y las suposiciones.
Si hace esto una vez, tiene una "tonelada" de pruebas que describen el comportamiento de su método.
4) En el siguiente paso, buscaría dependencias : ¿qué necesita el método además de su entrada para funcionar correctamente ? ¿Hay posibilidades de reducir o reestructurar esos? Cuantas menos dependencias tengas, más claro verás los puntos, dónde hacer las primeras divisiones.
5) A partir de ahí, puede recorrer todo el camino de refactorización con patrones de refactorización y refactorización a patrones.
Aquí un buen Vid: GoGaRuCo 2014- El método científico de resolución de problemas Se trata de la resolución de problemas, pero útil para una metodología general de comprensión de cómo funciona algo .
Usted menciona que la función llamada no tiene parámetros de entrada : en este caso especial, primero trataría de identificar las dependencias y refactorizarlas a parámetros, para que pueda intercambiarlas como desee.
