Einheit, die das Offensichtliche prüft

Question

Beim Versuch, Testfälle für eine Klasse zu schreiben, deren Funktionalität mehr mit Kesselblechcode als Geschäftslogik arbeitet. Ich begann mich zu fragen, ob Unit Testing wirklich für diesen Kurs wert ist. Aber dann, wenn TDD verwendet wird, ist es ratsam, einen Test für jede Logik, die wir hinzufügen, zu schreiben.

Als Beispiel die folgende Klasse verwendet nur DI, um Abhängigkeiten zu injizieren und Konfigurationsparameter zu erhalten, um den Ablauf der Anwendung einzurichten. Anders als bei Komponententests, wenn Abhängigkeiten korrekt injiziert werden, oder wenn beim Beenden der Befehl destroy aufgerufen wird (was das Unit-Testen des Java-CDI-Frameworks als mein eigener Code wäre), was kann ich sonst Unit-Test machen?

import javax.annotation.PostConstruct; 
import javax.annotation.PreDestroy; 
import javax.ejb.Singleton; 
import javax.ejb.Startup; 
import javax.ejb.TransactionAttribute; 
import javax.ejb.TransactionAttributeType; 
import javax.inject.Inject; 

@Singleton 
@Startup 
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) 
public class PipsAlprConnectionRunner { 
    @Inject 
    private PipsAlprConfiguration config; 

    @Inject 
    private PipsAlprConnector connector; 

    @Inject 
    private Scheduler scheduler; 

    @Inject 
    @PipsAlprAdapterService 
    private ServiceStatus status; 

    private Timer connectorTimer = null; 

    @PostConstruct 
    public void initialized() { 
     status.started(); 
     connectorTimer = scheduler.schedule(connector, 0, 
       1000 * config.getPollPeriodSeconds()); 
     status.operational(); 
    } 

    @PreDestroy 
    public void destroy() { 
     connectorTimer.cancel(); 
     connector.shutdown(); 
     status.stopped(); 
    } 
} 

ich nicht in der Lage war von irgendwelchen Testszenarien zu denken TDD zu nutzen, auf der oben genannten Klasse, kam so nur mit dem Code, und jetzt frage ich mich, was genau kann ich hier Unit-Test.

Answer 1

Nun, ein Fall kann gemacht werden, dass die Klasse etwas tut. Es ändert einen Status, es startet einen Timer. Sie können Mocks dieser Objekte über Mockito in die Klasse injizieren und dann sicherstellen, dass initialized() und destroy() beide tun, was Sie von diesen Mocks erwarten.

@RunWith(MockitoJUnitRunner.class) 
public class PipsAlprConnectionRunner { 

    @Mock 
    private PipsAlprConfiguration config; 

    @Mock 
    private PipsAlprConnector connector; 

    @Mock 
    private Scheduler scheduler; 

    @Mock 
    private ServiceStatus status;  

    @InjectMocks 
    private PipsAlprConnectionRunner pipsAlprConnectionRunner ; 

    @Test 
    public void initialized_should_set_status_started() { 
     pipsAlprConnectionRunner.initialized(); 
     Mockito.verify(status).started(); 
    } 

    // etc. 
} 

Es ist so ziemlich eine Frage des persönlichen Geschmacks, wenn Sie per „Point of Failure“ eine Methode erstellen möchten oder eine Methode pro Verfahren/Test.

Persönlich würde ich sagen, dass das Ziel 100% Abdeckung ist, also selbst ziemlich einfache Klassen, die hauptsächlich Delegieren sollten abgedeckt werden. Was passiert, wenn jemand etwas ändert? Der Test stellt sicher, dass solche Änderungen die vorhandene Funktionalität nicht beeinträchtigen.