Para hacer TDD es muy importante un framework como mockito, JUnit, para probar comportamientos y resultados sin necesidad de probar el código a grandes rasgos.
El TDD se escriben los test primero antes que escribir una línea de código de producción, escribir los test que testean el código de producción, aunque podría resultar difícil hacer si no se tiene código para compilar, entonces se debe de escribir lo mínimo para una compilación feliz. Un team hace TDD y a la misma vez que obtiene los test hechos, también al mismo tiempo se implementa la funcionalidad.
pude darme cuenta que es hasta meno permisivo por la consola que Nunca me entraba en la cabeza, mantener ese acople con arduino vía USB, me impendía explorar zona remotas con sensores, también que la api JSSC de Alexey Sokolov ya no es mantenida, solo un fork que veo bastante activa a la gente y es aquí jSerialComm.
Con instrumentación podemos hacer cosas con el bytecode antes y después que este sea subido/cargado a la JVM, aquí tengo 3 simples clases, un patético JFrame con una X=10; que eso puede representar desde la vida de un jugador o cualquier otro tipo de variable en cualquier aplicación java(escritorio, web app etc) con esta técnica podemos modificar ese valor.
Todo empezó una vez de esas que andaba aburrido como siempre, y ejecute un .jar al parecer cualquiera, pero en realidad no, era un server de adwind (un programador que me parecia bastante talentoso), año 2017 más o menos en Noviembre.
Pues como se eso? primeramente intente decompilarlo de otras maneras absurdas ajajaj como por ejemplo, con CFF Explorer, sin resultado alguno, ya que este no contiene runPE, pues lo supe después.
Esta es una versión vieja que programe en el 2016
inspirado en un post de security by default (post que sin el no estuviera aquí se los puedo jurar)
Modificar el application.properties
con usuario y contraseña, dicho correo debe tener habilitado el servidor smtp, usaremos gmail en este ejemplo