Come testare la classe astratta in Java con JUnit?

Sono nuovo ai test Java con JUnit. Devo lavorare con Java e vorrei utilizzare gli unit test.

Il mio problema è: ho una classe astratta con alcuni metodi astratti. Ma ci sono alcuni metodi che non sono astratti. Come posso testare questa classe con JUnit? Codice di esempio (molto semplice):

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

Voglio testare getSpeed()e getFuel()funzioni.

Una domanda simile a questo problema è qui , ma non sta usando JUnit.

Nella sezione FAQ di JUnit, ho trovato questo collegamento , ma non capisco cosa voglia dire l'autore con questo esempio. Cosa significa questa riga di codice?

public abstract Source getSource() ;

Se non hai implementazioni concrete della classe e i metodi no static testarli? Se hai una classe concreta, testerai quei metodi come parte dell'API pubblica della classe concreta.

So cosa stai pensando "Non voglio testare questi metodi più e più volte questo è il motivo per cui ho creato la classe astratta", ma la mia controargomentazione è che lo scopo degli unit test è consentire agli sviluppatori di apportare modifiche, eseguire i test e analizzare i risultati. Parte di questi cambiamenti potrebbe includere l'override dei metodi della tua classe astratta, sia protectede public, che potrebbe portare a cambiamenti comportamentali fondamentali. A seconda della natura di tali modifiche, potrebbe influire sul modo in cui l'applicazione viene eseguita in modi imprevisti, forse negativi. Se si dispone di una buona suite di unit test, i problemi derivanti da questi tipi di modifiche dovrebbero essere evidenti in fase di sviluppo.

Creare una classe concreta che erediti la classe astratta e quindi testare le funzioni che la classe concreta eredita dalla classe astratta.

Con la classe di esempio che hai pubblicato non sembra avere molto senso testare getFuel()egetSpeed() dal momento che possono restituire solo 0 (non ci sono setter).

Tuttavia, supponendo che questo fosse solo un esempio semplificato a scopo illustrativo e che tu abbia motivi legittimi per testare metodi nella classe base astratta (altri hanno già sottolineato le implicazioni), potresti impostare il tuo codice di test in modo che crei un anonimo sottoclasse della classe base che fornisce solo implementazioni fittizie (non opzionali) per i metodi astratti.

Ad esempio, nel tuo TestCasepotresti fare questo:

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

Quindi prova il resto dei metodi, ad esempio:

public class CarTest extends TestCase
{
    private Car c;

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

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

    [...]
}

(Questo esempio è basato sulla sintassi JUnit3. Per JUnit4, il codice sarebbe leggermente diverso, ma l'idea è la stessa.)

Se hai comunque bisogno di una soluzione (ad esempio perché hai troppe implementazioni della classe astratta e il test ripeterà sempre le stesse procedure) allora potresti creare una classe di test astratta con un metodo factory astratto che sarà eccitato dall'implementazione di quello classe di prova. Questo esempio funziona o me con TestNG:

La classe di prova astratta di 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);
    ...

Implementazione di Car

class ElectricCar extends Car {

    private final int batteryCapacity;

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

    ...

Classe ElectricCarTestdi unit test della Classe 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
    ...

Potresti fare qualcosa del genere

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

Creerei una classe interna jUnit che eredita dalla classe astratta. Questo può essere istanziato e avere accesso a tutti i metodi definiti nella classe astratta.

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


class ConcreteClass extends AbstractClass {

}

È possibile creare un'istanza di una classe anonima e quindi testarla.

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

Tieni presente che la visibilità deve essere protectedper la proprietà myDependencyServicedella classe astratta ClassUnderTest.

Puoi anche combinare questo approccio ordinatamente con Mockito. Vedi qui .

Il mio modo di testarlo è abbastanza semplice, all'interno di ciascuno abstractUnitTest.java. Creo semplicemente una classe in abstractUnitTest.java che estenda la classe astratta. E provalo in questo modo.

Non puoi testare l'intera classe astratta. In questo caso hai metodi astratti, questo significa che dovrebbero essere implementati da classi che estendono una data classe astratta.

In quella classe il programmatore deve scrivere il codice sorgente che è dedicato alla sua logica.

In altre parole, non si ha la sensazione di testare la classe astratta perché non si è in grado di verificarne il comportamento finale.

Se hai funzionalità importanti non correlate ai metodi astratti in qualche classe astratta, crea semplicemente un'altra classe in cui il metodo astratto genererà qualche eccezione.

Come opzione, puoi creare una classe di test astratta che copre la logica all'interno della classe astratta ed estenderla per ogni test di sottoclasse. In questo modo puoi assicurarti che questa logica venga testata separatamente per ogni bambino.