PHPUnit - Scrittura di una classe di test per un'interfaccia e test degli oggetti utilizzando una fabbrica

Question

Sto scrivendo una classe che erediterà un'interfaccia. Il codice client verrà scritto per quell'interfaccia e la classe scritta per supportarlo. L'idea è che in seguito scriverò altre classi per quell'interfaccia e gli oggetti di queste due classi differenti dovrebbero essere completamente intercambiabili. Piuttosto che scrivere una classe di test per quella prima lezione, voglio scriverne una per l'interfaccia.

Il mio piano era scrivere una classe di test che avrebbe preso un oggetto factory per il costruttore (dependency injection) e utilizzare la factory per creare nuove istanze della classe sottoposta a test.

In questo modo, se volessi testare ClassA, potrei passare un oggetto ClassAFactory al costruttore della classe di test e, se volessi testare ClassB, passerei un oggetto ClassBFactory. Entrambe le classi sono progettate per essere intercambiabili e dato che solo i metodi pubblici dovrebbero essere testati, questo sembra l'ideale.

Ma che dire del test del costruttore? Farei meglio a scrivere una classe di test astratta e a impiantare test del costruttore in classi che ereditano la classe di test astratta (diverse classi possono essere istanziate in modo diverso)?

Se ho usato la prima idea, credo che avrei avuto una classe di test per ogni classe in fase di sperimentazione, come:

class ClassATest extends [PHPUnit test case] 
{ 
    $myFactory = new ClassAFactory(); 
    $myTest = new ClassTest($myFactory); 

    $myTest->test1(); 
    $myTest->test2(); 
    //etc. 
} 

Qual è il modo migliore per andare su questo? Voglio fare un test generale, in modo che quando scrivo nuove classi per implementare l'interfaccia comune, posso semplicemente mettere un oggetto degli stessi test usati per gli altri. Ma visto che le diverse classi avrebbero costruttori diversi, forse scrivere una classe di test astratta ed estenderla per ogni nuovo oggetto sarebbe meglio? Cosa ne pensi?

Answer 1

Penso che sia necessario riconsiderare il piano. Non è possibile testare un'interfaccia e c'è una buona ragione per cui - le interfacce definiscono semplicemente l'API e non la funzionalità, la funzionalità di test dei test. Permettetemi di darvi un esempio che potrebbe aiutare. Supponiamo tu abbia un'interfaccia "di messaggistica". Quindi implementa un EmailMessager e un SMSMessager. Ora devi testarli separatamente come con l'EmailMessager di cui hai bisogno per assicurarti che stia facendo la sua roba, magari convalidando il destinatario (un indirizzo email) e possibilmente delegando l'invio a una classe email ecc. Ovviamente un messaggio SMS sarebbe diverso.

Answer 2

È possibile creare un test case astratto con tutti i metodi di test utilizzando una proprietà che ciascuna sottoclasse imposterà senza richiedere una factory. Può testare le qualità fisse che tutte le implementazioni devono possedere.

abstract class IAdderTestCase extends PFTC 
{ 
    function testAdd() { 
     self::assertEquals(5, $this->fixture->add(2, 3)); 
    } 
    ... 
} 

class BasicAdderTest extends IAdderTestCase 
{ 
    function setUp() { 
     $this->fixture = new BasicAdder(); 
    } 
} 

PHPUnit chiamerà setUp() prima di ogni metodo di prova. Dovrebbe chiamare tutti i metodi di test ereditati per ciascuna sottoclasse di calcestruzzo più eventuali altri, ad es. per testare i costruttori.