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?
Oboje działają. Postanowiłem użyć techniki '@ Capturing'. Dzięki za pomoc! – rdguam