Як протестувати абстрактний клас на Java за допомогою JUnit?

Я новачок у тестуванні Java за допомогою JUnit. Я повинен працювати з Java, і я хотів би використовувати модульні тести.

Моя проблема полягає в тому, що я маю абстрактний клас з деякими абстрактними методами. Але є деякі методи, які не є абстрактними. Як я можу протестувати цей клас за допомогою JUnit? Приклад коду (дуже простий):

abstract class Car {

    public Car(int speed, int fuel) {
        this.speed = speed;
        this.fuel = fuel;
    }

    private int speed;
    private int fuel;

    abstract void drive();

    public int getSpeed() {
        return this.speed;
    }

    public int getFuel() {
        return this.fuel;
    }
}

Я хочу тестувати getSpeed()та getFuel()функціонувати.

Подібне запитання до цієї проблеми є і тут , але воно не використовує JUnit.

У розділі поширених запитань про JUnit я знайшов це посилання , але не розумію, що автор хоче сказати на цьому прикладі. Що означає цей рядок коду?

public abstract Source getSource() ;

Якщо у вас немає конкретних реалізацій класу, а методи не є staticсенсом перевіряти їх? Якщо у вас є конкретний клас, ви будете тестувати ці методи як частину загальнодоступного API конкретного класу.

Я знаю, про що ви думаєте: "Я не хочу перевіряти ці методи знову і знову, саме тому я створив абстрактний клас", але мій аргумент протилежності полягає в тому, що сенс модульних тестів - дозволити розробникам вносити зміни, запустити тести та проаналізувати результати. Частина цих змін може включати перевизначення методів вашого абстрактного класу, як protectedі public, що може призвести до фундаментальних змін у поведінці. Залежно від характеру цих змін це може вплинути на те, як ваша програма працює несподіваними, можливо негативними способами. Якщо у вас хороший пакет модульних тестів, проблеми, що виникають внаслідок цих типів, повинні бути очевидними під час розробки.

Створіть конкретний клас, який успадковує абстрактний клас, а потім протестуйте функції, які конкретний клас успадковує від абстрактного класу.

З прикладом класу, який ви опублікували, здається, немає сенсу тестувати, getFuel()і getSpeed()оскільки вони можуть повернути лише 0 (сетерів немає).

Однак, припускаючи, що це був лише спрощений приклад для ілюстративних цілей, і у вас є законні причини для тестування методів в абстрактному базовому класі (інші вже вказували на наслідки), ви можете налаштувати свій тестовий код так, щоб він створював анонімний підклас базового класу, який просто забезпечує фіктивні (не-оперативні) реалізації для абстрактних методів.

Наприклад, у вашому TestCaseви можете зробити це:

c = new Car() {
       void drive() { };
   };

Потім протестуйте інші методи, наприклад:

public class CarTest extends TestCase
{
    private Car c;

    public void setUp()
    {
        c = new Car() {
            void drive() { };
        };
    }

    public void testGetFuel() 
    {
        assertEquals(c.getFuel(), 0);
    }

    [...]
}

(Цей приклад базується на синтаксисі JUnit3. Для JUnit4 код буде дещо іншим, але ідея однакова.)

Якщо в будь-якому випадку вам потрібне рішення (наприклад, тому що у вас забагато реалізацій абстрактного класу, і тестування завжди повторювало б однакові процедури), ви можете створити абстрактний тестовий клас із абстрактним фабричним методом, який буде виконаний реалізацією цього тестовий клас. Ці приклади працюють або я з TestNG:

Абстрактний тестовий клас Car:

abstract class CarTest {

// the factory method
abstract Car createCar(int speed, int fuel);

// all test methods need to make use of the factory method to create the instance of a car
@Test
public void testGetSpeed() {
    Car car = createCar(33, 44);
    assertEquals(car.getSpeed(), 33);
    ...

Впровадження Car

class ElectricCar extends Car {

    private final int batteryCapacity;

    public ElectricCar(int speed, int fuel, int batteryCapacity) {
        super(speed, fuel);
        this.batteryCapacity = batteryCapacity;
    }

    ...

Одиниця тестовий клас ElectricCarTestз класу ElectricCar:

class ElectricCarTest extends CarTest {

    // implementation of the abstract factory method
    Car createCar(int speed, int fuel) {
        return new ElectricCar(speed, fuel, 0);
    }

    // here you cann add specific test methods
    ...

Ви могли б зробити щось подібне

public abstract MyAbstractClass {

    @Autowire
    private MyMock myMock;        

    protected String sayHello() {
            return myMock.getHello() + ", " + getName();
    }

    public abstract String getName();
}

// this is your JUnit test
public class MyAbstractClassTest extends MyAbstractClass {

    @Mock
    private MyMock myMock;

    @InjectMocks
    private MyAbstractClass thiz = this;

    private String myName = null;

    @Override
    public String getName() {
        return myName;
    }

    @Test
    public void testSayHello() {
        myName = "Johnny"
        when(myMock.getHello()).thenReturn("Hello");
        String result = sayHello();
        assertEquals("Hello, Johnny", result);
    }
}

Я б створив внутрішній клас jUnit, який успадковується від абстрактного класу. Це може бути інстанційовано і мати доступ до всіх методів, визначених у абстрактному класі.

public class AbstractClassTest {
   public void testMethod() {
   ...
   }
}


class ConcreteClass extends AbstractClass {

}

Ви можете створити екземпляр анонімного класу, а потім протестувати цей клас.

public class ClassUnderTest_Test {

    private ClassUnderTest classUnderTest;

    private MyDependencyService myDependencyService;

    @Before
    public void setUp() throws Exception {
        this.myDependencyService = new MyDependencyService();
        this.classUnderTest = getInstance();
    }

    private ClassUnderTest getInstance() {
        return new ClassUnderTest() {    
            private ClassUnderTest init(
                    MyDependencyService myDependencyService
            ) {
                this.myDependencyService = myDependencyService;
                return this;
            }

            @Override
            protected void myMethodToTest() {
                return super.myMethodToTest();
            }
        }.init(myDependencyService);
    }
}

Майте на увазі, що видимість має бути protectedвластивістю myDependencyServiceабстрактного класу ClassUnderTest.

Ви також можете акуратно поєднати цей підхід з Mockito. Дивіться тут .

Мій спосіб перевірити це досить просто в межах кожного abstractUnitTest.java. Я просто створюю клас у abstractUnitTest.java, який розширює абстрактний клас. І перевірити це таким чином.

Ви не можете перевірити цілий абстрактний клас. У цьому випадку у вас є абстрактні методи, це означає, що вони повинні бути реалізовані класом, який поширюється на даний абстрактний клас.

У цьому класі програміст повинен написати вихідний код, який присвячений його логіці.

Іншими словами, немає сенсу тестування абстрактного класу, оскільки ви не можете перевірити остаточну поведінку його.

Якщо у вас є основна функціональність, не пов’язана з абстрактними методами в якомусь абстрактному класі, просто створіть інший клас, де абстрактний метод викличе якийсь виняток.

Як варіант, ви можете створити абстрактний тестовий клас, що охоплює логіку всередині абстрактного класу, і розширити його для кожного тесту підкласу. Так що таким чином ви зможете забезпечити тестування цієї логіки для кожної дитини окремо.