2011-07-20 12 views
5

Biorąc pod uwagę hierarchię klas, który wygląda tak:Jak zapobiec kpiny z klasy super przez 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"; 
    } 

} 

próbuję przetestować klasę samochodu. Jednak zdarza się również, że samochód korzysta z magistrali. Tak więc w moim teście próbuję wyśmiać Busa. Mój kod testowy wygląda następująco:

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()); 
    } 

} 

assert nie dlatego car.getName() zwraca null.

Wstawiając System.out.println JEST W konstruktorów do pojazdów, samochodów i autokarów, mam podejrzenie, że «prawdziwe» pojazd, który jest ładowany przez new Car(name) jest później zastąpiony przez wyśmiewali Pojazd gdy @Mocked Bus bus jest wykonywany.

Czy istnieje sposób na to, aby jmockit zachował prawdziwy Pojazd, który jest "tworzony w czasie" podczas budowy samochodu?

Odpowiedz

1

Widzę dwa rozwiązania:

@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

Oboje działają. Postanowiłem użyć techniki '@ Capturing'. Dzięki za pomoc! – rdguam

0

Brak pojazdu "powiązanego" z samochodem - samochód jest pojazdem. Stowarzyszenie i dziedziczenie to nie to samo. Dlatego nie można mieć samochodu z "wyśmianym" pojazdem - to zdanie nie ma znaczenia, gdy Car extends Vehicle.

Czy na pewno nie ma (legit) błędu w konstruktorze samochodu lub getName()? Jak wygląda kod dla tych metod?

+0

będę aktualizować z kodem dla trzech klas. – rdguam

+1

i co się stanie, jeśli usuniesz z testowania jednostkowego rzeczy "new NonStrictExpectations() {@Mocked ...", aby dokładnie przetestować konstruktor samochodu i funkcję 'getName()'? Czy test przebiega bez kpiny? Coś tu nie pasuje. –

+0

Tak, test przechodzi, jeśli skomentuję "nowe NonStrictExpectations() {...};". – rdguam

Powiązane problemy