2011-07-20 6 views
5

dado una jerarquía de clases que tiene este aspecto:¿Cómo evitar que supermodelo sea burlado por jmockit?

public class Vehicle { 

    private String name; 

    public Vehicle(String name) { 
     this.name = name; 
    } 

    public String getName() { 
     return name; 
    } 

} 


public class Car extends Vehicle { 

    public Car(String name) { 
     super(name); 
    } 

    public String drive() { 
     return "driving the car"; 
    } 

    public String boardBus() { 
     Bus bus = new Bus("bus to cut off"); 

     return bus.board(); 
    } 

} 

public class Bus extends Vehicle { 

    public Bus(String name) { 
     super(name); 
    } 

    public String board() { 
     return "boarding the bus"; 
    } 

} 

Estoy intentando probar la clase de coche. Sin embargo, Car también hace uso de Bus. Entonces, en mi prueba, estoy tratando de burlarme de Bus. Mi código de prueba es el siguiente:

import static org.junit.Assert.assertEquals; 
import mockit.Mocked; 
import mockit.NonStrictExpectations; 

import org.junit.Test; 

public class CarTest { 

    @Test 
    public void testCar() { 
     final String name = "I am a car"; 
     final Car car = new Car(name); 

     new NonStrictExpectations() { 
      @Mocked Bus bus; 

      { 
       bus.board(); result = "test bus boarding"; 
      } 
     }; 

     assertEquals("I am a car", car.getName()); 
    } 

} 

la aserción falla porque car.getName() devuelve null.

Mediante la inserción de System.out.println 's de los constructores de vehículos, coches y autobuses, estoy sospechando que el vehículo 'real' que se carga por new Car(name) se sustituye después por un vehículo burlado cuando se ejecuta el @Mocked Bus bus.

¿Hay alguna manera de que jmockit preserve el vehículo real que se "instancia" cuando se construye el automóvil?

Respuesta

1

veo dos soluciones:

@Test 
public void boardBus_usingInstanceSpecificMockingForNewedInstances() 
{ 
    new Expectations() { 
     @Capturing @Injectable Bus bus; 

     { 
      bus.board(); result = "mocked"; 
     } 
    }; 

    String result = new Car("myCar").boardBus(); 
    assertEquals("mocked", result); 
} 

@Test 
public void boardBus_usingPartialMocking() 
{ 
    final Bus bus = new Bus(""); 
    new Expectations(bus) {{ bus.board(); result = "mocked"; }}; 

    String result = new Car("myCar").boardBus(); 
    assertEquals("mocked", result); 
} 
+1

Ambos trabajan. Decidí usar la técnica '@ Capturing'. ¡Gracias por la ayuda! – rdguam

0

No hay Vehículo "asociado" con un coche - El coche es un vehículo. La asociación y la herencia no son lo mismo. Por lo tanto, no es posible tener un automóvil con un vehículo "burlado"; esta frase no tiene sentido cuando Car extends Vehicle.

¿Estás seguro de que no hay un error (de fiar) en el constructor del coche ni en el getName()? ¿Cómo se ve el código de estos métodos?

+0

voy a actualizar con el código para las tres clases. – rdguam

+1

y ¿qué ocurre si elimina las 'nuevas cosas de NonStrictExpectations() {@Mocked ...' de la prueba unitaria, simplemente para probar el constructor de Auto y 'getName()'? ¿Hace una prueba sin ningún burla? Algo no se resume aquí. –

+0

Sí, la prueba pasa si comento las 'nuevas NonStrictExpectations() {...};'. – rdguam

Cuestiones relacionadas