PowerMock + Mockito VS Mockito solo

No conozco otros beneficios de repente, pero quiero abordar 2 de sus sub-preguntas (y esto es demasiado largo para un comentario):

Permitir burlarse sin inyección de dependencia - esto no está claro para mí. ¿Puedes explicarlo?

Creo que esto vino de la página wiki de motivación donde describen una forma de refactorizar código para no invocar métodos estáticos para hacerlo comprobable. Para un ejemplo concreto de lo que creo que quieren decir, digamos que tienes este código y desea probar el método burlándose del comportamiento del método estático, sin usar powermock:

public class MyClass {
     public void doGetString() {
         ...
         OtherClass.getString(); //It's complex and scary and needs mocking!
         ...
     }
}

Una solución, sería tirar de la invocación estática en su propio objeto, a continuación, inyectar un objeto que puede ser burlado llegado el tiempo de prueba. Por ejemplo, sin usar otros frameworks, esto podría verse como:

public class MyClass {
     public static class StringGetter {
         public getString() {
             return OtherClass.getString();                 
         }
     }

     private final StringGetter getter;

     //Existing Constructor
     public MyClass() {
         this(new StringGetter());
     }

     //DI Constructor
     MyClass(StringGetter getter) {
         this.getter = getter;
     }

     public void doGetString() {
         ...
         getter.getString();
         ...
     }
}

He separado el comportamiento de mi método del comportamiento de la invocación estática, y puedo usar el constructor DI para inyectar simulaciones fácilmente en la prueba tiempo. Por supuesto, con Powermock podría simplemente burlarme del método estático en su lugar, y ejecutar con él.

¿Y necesito sacrificar algo cuando uso PowerMock?

Físicamente no, pero yo diría filosóficamente sí :). Las siguientes son mis opiniones, y trato de dar buenas razones detrás de ellas, pero por supuesto que son opiniones, así que tómalas con un grano de sal:

La cosa potencialmente aterradora que está sucediendo con PowerMock es que con el fin de lograr las hazañas de burlándose de métodos privados y estáticos, están usando un cargador de clases personalizado (que no debería estar presente en tiempo de ejecución en producción) y cambiando el bytecode de sus clases. Podría decirse que esto no debería importar con la gran mayoría de las clases la mayor parte del tiempo, pero si lo piensas, si el bytecode ha cambiado y ciertos efectos secundarios ya no están presentes, estás probando efectivamente diferentes Clases albiet basadas en tus clases existentes. Si este es un argumento muy académico.

Usted puede mitigar un poco este primer argumento al tener una buena integración integral y pruebas de nivel superior que no usan PowerMock. De esta manera puede tener más confianza en el comportamiento de sus objetos incluso si sus pruebas unitarias están utilizando PowerMock.

El otro argumento que tengo contra PowerMock, es que podría casi demasiado fácilmente convertirse en una muleta. Estoy de acuerdo en que PowerMock puede ayudar con el código de prueba que utiliza código heredado y otro código sobre el que usted no tiene control. Sin embargo lo haría argumenta que cuando tienes control sobre las clases que necesitas burlarte, debes evitar su uso. Si usted escribe una clase con un método privado o método estático que necesitan explícitamente simulacros para probar otros métodos, mi instinto diría que este método se puede hacer demasiado y debe ser refactorizado y roto. Al tener PowerMock ya disponible en un proyecto, puede verse tentado a simplemente burlarse de él y seguir adelante, lo que mitigaría el dolor que debería alentarlo a refactorizar el igual. Sí, a veces, debido a varias limitaciones técnicas y no técnicas, esto no es posible, pero es bueno resolver los puntos débiles en lugar de evitarlos:)