2010-05-25 20 views
7

Estoy tratando de aprender a escribir pruebas. También estoy aprendiendo Java, me dijeron que debería aprender/uso jMock/práctica, he encontrado algunos artículos en línea que ayuda a extender determinado como:Cómo comenzar a probar (jMock)

http://www.theserverside.com/news/1365050/Using-JMock-in-Test-Driven-Development

http://jeantessier.com/SoftwareEngineering/Mocking.html#jMock

Y la mayoría de los artículos Descubrí que se trata de desarrollo impulsado por pruebas, escribir pruebas primero y luego escribir el código para que pase la prueba. No estoy buscando eso en este momento, estoy tratando de escribir pruebas para el código ya existente con jMock.

El official documentation es vago, por decir lo menos, y demasiado duro para mí. ¿Alguien tiene una mejor manera de aprender esto? Los buenos libros/enlaces/tutoriales me ayudarían mucho. gracias

EDITAR - pregunta más concreta:

http://jeantessier.com/SoftwareEngineering/Mocking.html#jMock - de este artículo

probado este para burlarse de esta clase simple:

import java.util.Map; 
    public class Cache { 
     private Map<Integer, String> underlyingStorage; 
     public Cache(Map<Integer, String> underlyingStorage) { 
      this.underlyingStorage = underlyingStorage; 
     } 
     public String get(int key) { 
      return underlyingStorage.get(key); 
     } 
     public void add(int key, String value) { 
      underlyingStorage.put(key, value); 
     } 
     public void remove(int key) { 
      underlyingStorage.remove(key); 
     } 
     public int size() { 
      return underlyingStorage.size(); 
     } 
     public void clear() { 
      underlyingStorage.clear(); 
     } 
    } 

Así es como he tratado de crear una prueba/simulacro:

public class CacheTest extends TestCase { 

    private Mockery context; 
    private Map mockMap; 
    private Cache cache; 

    @Override 
    @Before 
    public void setUp() { 
     context = new Mockery() { 
      { 
       setImposteriser(ClassImposteriser.INSTANCE); 
      } 
     }; 

     mockMap = context.mock(Map.class); 
     cache = new Cache(mockMap); 
    } 

    public void testCache() { 
     context.checking(new Expectations() {{ 
      atLeast(1).of(mockMap).size(); 
      will(returnValue(int.class)); 
     }}); 

    } 
} 

Pasa la prueba y, básicamente, no hace nada, lo que quería es crear un mapa y comprobar su tamaño, y usted sabe trabajar algunas variaciones para tratar de entender esto. Comprender mejor a través de ejemplos, qué más podría probar aquí o cualquier otro ejercicio me ayudaría mucho. tnx

+1

No es una respuesta pero: recomendaría aprender a escribir pruebas antes de mirar en los simulacros. Los simulacros son un tema avanzado en las pruebas, primero debe dominar los conceptos básicos. – Arne

+0

@Arne ¿Puede darme una respuesta concreta sobre lo que se considera básico? Soy un aprendiz rápido, sin decir que soy más inteligente que otras personas, estoy ansioso por aprender y tengo mucho tiempo libre. Entonces, si una cosa se vuelve aburrida, puedo pasar a la otra simple/avanzada que realmente no importa. tnx – London

+0

Puede escribir sus pruebas sin un marco de burla. Solo usa JUnit para escribir tus pruebas. Si está probando su código con fluidez y luego se encuentra con un caso que no puede dominar sin un simulacro, intente con un marco burlón. La necesidad de un simulacro debería ser la excepción, no la regla. – Arne

Respuesta

5

Aquí hay un tutorial sobre el uso de JUnit y EasyMock (una biblioteca de burla personalmente encuentro mucho más fácil de usar que JMock): http://www.michaelminella.com/testing/unit-testing-with-junit-and-easymock.html

Incluso si está 100% dedicado a usar JMock, los conceptos entre los dos son los mismos y esto debería ayudarlo a comprenderlos mejor.

El propósito de burla es que cuando se prueba Clase A, que depende de B y C, su prueba de A utiliza versiones simuladas de B y C ser capaz de especificar su comportamiento exacto en lugar de utilizar las implementaciones reales de B y C en su prueba de A.De lo contrario, no está probando solo la unidad de A, está implícitamente probando B y C también.

+0

puede/se burla de los constructores, ya que no son métodos, todavía estoy luchando para entender todo. – London

+0

Algunas bibliotecas admiten clases de burla y no solo interfaces (EasyMock 3.0 lo afirma), pero no estoy muy familiarizado con ellas. La burla brilla cuando tus clases expresan dependencias entre ellas dependiendo de una * interfaz * y no una * clase concreta *. –

1

No sé cuánto has avanzado en el camino para aprender sobre el uso de objetos simulados en las pruebas, así que escribiré una breve descripción y luego te indicaré un artículo que puede ser útil para tú. Los objetos simulados se utilizan en pruebas unitarias para reemplazar dependencias externas que son difíciles de crear o difíciles de obtener en el estado que desea para su prueba. Los diversos marcos de burla que existen le brindan mecanismos para crear objetos "falsos" que toman el lugar de estas dependencias. Estos objetos falsos realizarán un seguimiento de las llamadas que ingresan desde su código y le permitirán hacer afirmaciones sobre estas interacciones más adelante. Hay un artículo bien conocido sobre objetos falsos y cómo se relacionan con "stubs", otra estrategia de prueba común para simplificar las dependencias externas. Fue escrito por Martin Fowler y se puede encontrar aquí:

http://martinfowler.com/articles/mocksArentStubs.html

+0

puede/se burla de los constructores, ya que no son métodos, todavía estoy luchando para entender todo. – London

+0

No, la burla se realiza a nivel de clase, por lo que el marco de burlas se encargará de crear el objeto "proxy" (es decir, falso) para usted. Tenga en cuenta que este objeto no implementa el comportamiento del objeto que se burla. Su propósito es hacer un seguimiento de las interacciones con él y permitirle verificar que estas interacciones ocurrieron tal como esperabas. –

+0

gracias por su explicación, ¿cómo puedo probar algunos de estos métodos? – London

2

No necesita simulacro para probar esta clase, ya que su único colaborador es un Mapa que también podría usar tal cual. Además, tu clase realmente no hace nada (excepto delegar) y es por eso que sientes que no estás probando mucho.

Una prueba podría ser recta (Asumo que está utilizando JUnit 4 - su código es una extraña mezcla de JUnit 3 y 4

@Test 
public void sizeIs0WhenEmpty() 
{ 
    Map<Integer, String> map = Collections.emptyMap(); 
    Cache cache = new Cache(map) 
    assertEquals(0, cache.size()); 
} 

con burla sería (suponiendo que el código es fingida correcta - no uso JMock)

@Test 
public void sizeIs0WhenEmpty() 
{ 
    context.checking(new Expectations() {{ 
        atLeast(1).of(mockMap).size(); 
        will(returnValue(0)); 
        }}); 
    assertEquals(0, cache.size()); 
} 

En ambos casos, la configuración del sistema mediante el establecimiento del mapa para tener las propiedades que desea probar y luego verificar que la memoria caché tiene las mismas propiedades (como es un delegado directo).

Le recomendaría que lea about JUnit antes de continuar.

4

Como autor de JMock, no comenzaría con la técnica hasta que tenga alguna experiencia con TDD. Solo comienza con lo básico y haz que funcione. Una vez que comience a experimentar dificultades con la escala y el crecimiento de un diseño, vuelva a la técnica.

El libro de Dave Astels sigue siendo una buena introducción y el único, creo, de esa generación que explica se burla bien. Después de eso, podría (ejem) considerar el nuestro, "Crecimiento de software orientado a objetos, guiado por pruebas"

Descuente a cualquier persona que le diga que todo se trata de hacer que las pruebas contra el sistema de archivos sean más rápidas.