¿Cuál es el mejor marco simulado para Java?

Question

¿Cuál es el mejor marco para crear objetos simulados en Java? ¿Por qué? ¿Cuáles son los pros y los contras de cada marco?

Answer 1

He tenido un buen éxito usando Mockito.

Cuando traté de aprender sobre JMock y EasyMock, encontré que la curva de aprendizaje era un poco abrupta (aunque tal vez sea solo yo).

Me gusta Mockito por su sintaxis simple y limpia que pude comprender bastante rápido. La sintaxis mínima está diseñada para soportar muy bien los casos comunes, aunque las pocas veces que necesité hacer algo más complicado encontré que lo que quería era compatible y fácil de entender.

He aquí un ejemplo (abreviada) de la página de inicio Mockito:

import static org.mockito.Mockito.*; 

List mockedList = mock(List.class); 
mockedList.clear(); 
verify(mockedList).clear(); 

No puede ser mucho más simple que eso.

El único inconveniente importante que puedo pensar es que no se burlará de los métodos estáticos.

Answer 2

Estamos utilizando en gran medida EasyMock y EasyMock Class Extension en el trabajo y estamos muy contentos con él. Básicamente te da todo lo que necesitas. Eche un vistazo a la documentación, hay un buen ejemplo que le muestra todas las características de EasyMock.

Answer 3

Empecé a usar simulaciones a través de JMock, pero finalmente hice la transición para usar EasyMock. EasyMock era solo eso, más fácil, y proporcionaba una sintaxis que parecía más natural. No he cambiado desde entonces.

Answer 4

Mockito también proporciona la opción de métodos de anotación, haciendo coincidir los argumentos (como anyInt() y anyString()), verificando el número de invocaciones (times (3), atLeastOnce(), never()), and more.

También he encontrado que Mockito es simple and clean.

Una cosa que no me gusta de Mockito es que usted can't stub static methods.

Answer 5

Sí, Mockito es un gran marco. Lo uso junto con hamcrest y Google guice para configurar mis pruebas.

Answer 6

También puede echar un vistazo a las pruebas con Groovy. En maravilloso que pueda fácilmente interfaces de simulacros de Java utilizando el 'como' operador:

def request = [isUserInRole: { roleName -> roleName == "testRole"}] as HttpServletRequest 

Además de esta funcionalidad básica maravilloso ofrece mucho más en la parte frontal de burla, incluyendo los poderosos MockFor y StubFor clases.

http://docs.codehaus.org/display/GROOVY/Groovy+Mocks

Answer 7

He tenido éxito con JMockit.

Es bastante nuevo, por lo que es un poco crudo y poco documentado. Utiliza ASM para redefinir dinámicamente el bytecode de clase, por lo que puede simular todos los métodos, incluidos los generadores estáticos, privados, constructores e iniciadores estáticos.Por ejemplo:

import mockit.Mockit; 

... 
Mockit.redefineMethods(MyClassWithStaticInit.class, 
         MyReplacementClass.class); 
... 
class MyReplacementClass { 
    public void $init() {...} // replace default constructor 
    public static void $clinit{...} // replace static initializer 
    public static void myStatic{...} // replace static method 
    // etc... 
} 

Cuenta con una interfaz expectativas permitiendo escenarios de grabación/reproducción, así:

import mockit.Expectations; 
import org.testng.annotations.Test; 

public class ExpecationsTest { 
    private MyClass obj; 

    @Test 
    public void testFoo() { 
    new Expectations(true) { 
     MyClass c; 
     { 
     obj = c; 
     invokeReturning(c.getFoo("foo", false), "bas"); 
     } 
    }; 

    assert "bas".equals(obj.getFoo("foo", false)); 

    Expectations.assertSatisfied(); 
    } 

    public static class MyClass { 
    public String getFoo(String str, boolean bool) { 
     if (bool) { 
     return "foo"; 
     } else { 
     return "bar"; 
     } 
    } 
    } 
} 

La desventaja es que requiere Java 5/6.

Answer 8

Me gusta JMock porque puede establecer expectativas. Esto es totalmente diferente de verificar si se llamó un método encontrado en algunas bibliotecas falsas. Usando JMock puedes escribir expectativas muy sofisticadas. Ver el jmock cheat-sheat.

Answer 9

Soy el creador de PowerMock, así que obviamente debo recomendarlo. :-)

PowerMock amplía tanto EasyMock como Mockito con la capacidad de mock static methods, métodos finales e incluso privados. El soporte de EasyMock está completo, pero el plugin de Mockito necesita más trabajo. Estamos planeando agregar compatibilidad con JMock también.

PowerMock no está destinado a reemplazar otros marcos, sino que se puede usar en las situaciones complicadas cuando otros marcos no permiten la burla. PowerMock también contiene otras características útiles como suppressing static initializers y constructores.

Answer 10

La mejor solución para burlarse es hacer que la máquina haga todo el trabajo con pruebas automatizadas basadas en especificaciones. Para Java, vea ScalaCheck y el marco Reductio incluido en la biblioteca Functional Java. Con los marcos de prueba basados ​​en especificaciones automatizadas, usted proporciona una especificación del método bajo prueba (una propiedad al respecto que debería ser cierta) y el marco genera pruebas y simulacros de objetos automáticamente.

Por ejemplo, la siguiente propiedad prueba el método Math.sqrt para ver si la raíz cuadrada de cualquier número positivo n al cuadrado es igual a n.

val propSqrt = forAll { (n: Int) => (n >= 0) ==> scala.Math.sqrt(n*n) == n } 

Cuando se llama a propSqrt.check(), ScalaCheck genera cientos de números enteros y comprueba su propiedad para cada uno, que también hace de forma automática asegurarse de que los casos extremos están cubiertos también.

Aunque ScalaCheck está escrito en Scala y requiere el Scala Compiler, es fácil probar el código Java con él. El marco de Reductio en Functional Java es una implementación pura de Java con los mismos conceptos.

Answer 11

Para algo un poco diferente, puede usar JRuby y Mocha que se combinan en JtestR para escribir pruebas para su código Java en Ruby expresivo y sucinto. Hay algunos ejemplos de burla útiles con JtestR here. Una ventaja de este enfoque es que burlarse de las clases concretas es muy sencillo.

Answer 12

El JMockit project site contiene mucha información comparativa para los kits de herramientas de burla actuales.

En particular, revisar la feature comparison matrix, que cubre EasyMock, jMock, Mockito, Unitils Mock, PowerMock, y de JMockit curso. Trato de mantenerlo preciso y actualizado, tanto como sea posible.

Answer 13

Utilicé JMock temprano. Intenté con Mockito en mi último proyecto y me gustó. Más conciso, más limpio. PowerMock cubre todas las necesidades que faltan en Mockito, como burlarse de un código estático, burlarse de una creación de instancia, burlarse de las clases y métodos finales.Entonces tengo todo lo que necesito para realizar mi trabajo.

Answer 14

Empecé a usar simulaciones con EasyMock. Lo suficientemente fácil de entender, pero el paso de reproducción fue un poco molesto. Mockito elimina esto, también tiene una sintaxis más limpia, ya que parece que la legibilidad fue uno de sus objetivos principales. No puedo enfatizar lo importante que es esto, ya que la mayoría de los desarrolladores pasarán su tiempo leyendo y manteniendo el código existente, no creándolo.

Otra cosa agradable es que las interfaces y las clases de implementación se manejan de la misma manera, a diferencia de EasyMock, donde todavía debe recordar (y verificar) el uso de una extensión de clase EasyMock.

He echado un vistazo rápido a JMockit recientemente, y si bien la lista de funciones es bastante exhaustiva, creo que el precio de esto es la legibilidad del código resultante y tener que escribir más.

Para mí, Mockito da en el clavo, es fácil de escribir y leer, y maneja la mayoría de las situaciones que la mayoría del código requerirá. Usar Mockito con PowerMock sería mi elección.

Una cosa a considerar es que la herramienta que elegirías si estuvieras desarrollando por ti mismo, o en un equipo pequeño y compacto, podría no ser la mejor opción para una gran compañía con desarrolladores de diferentes niveles de habilidad. La legibilidad, la facilidad de uso y la simplicidad necesitarían más consideración en este último caso. No tiene sentido obtener el marco de burla definitivo si muchas personas terminan no usándolo o no manteniendo las pruebas.