Come verificare lo stato dell'oggetto

Question

Come verificare lo stato dell'oggetto

#1 da (2 voti)
#2 da (1 voti)
#3 da (0 voti)

2

Ho una classe DataImport con solo due metodi pubblici

public void fromStream(InputStream inputStream);
public ImportCommand getImportCommand();

Quando eseguo il test, invio alcuni dati di test al metodo fromStream

dataImport.fromStream(some stream with data...)

Solo come testare il risultato di questo metodo è ottenere il ImportCommand da getImportCommand e testare se questo oggetto si trova nello stato in base all'input fornito.

Ma cosa succede se ImportCommand ha un solo metodo?

public ImportResult execute();

Potrei testare ImportResult (dopo aver richiamato execute() che implicherebbe alcuni mock e impostazioni aggiuntive) perché ha qualche stato esposto. Ma in questo modo sto testando ImportCommand e la classe DataImport in un test di unità che non mi sembra giusto.

Ma esporre lo stato interiore delle classi che sto testando o accedere ai loro campi / metodi privati non è una buona cosa.

Questo significa che il mio design non è ok (come dovrei cambiarlo) o c'è un modo per risolvere questa situazione?

Contenuti correlati: anti-pattern TDD su SO

tdd java

posta DominikM 25.04.2014 - 13:26

fonte

3 risposte

1

Nei test unitari, dovresti sempre testare il comportamento dei tuoi oggetti e non lo stato. TDD è utile quando progetti le tue API, in questo caso hai già deciso come apparirà l'API e hai problemi a testarlo.

IMO DataImport è un'astrazione superflua. Può essere un metodo da qualche altra parte.

risposta data 26.04.2014 - 08:15

fonte

0

Avere una restrizione sull'interfaccia come,

... class DataImport with only two public methods

è valido e non implica in alcun modo che il tuo design non sia a posto. In effetti sarebbe brutto ingombrare l'interfaccia con metodi solo per test.

Al contrario, puoi utilizzare segregazione dell'interfaccia per aumentare la testabilità della classe e presentare viste separate.

The interface-segregation principle (ISP) states that no client should be forced to depend on methods it does not use. ISP splits interfaces which are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them. Such shrunken interfaces are also called role interfaces. ISP is intended to keep a system decoupled and thus easier to refactor, change, and redeploy. ISP is one of the five SOLID principles of Object-Oriented Design

In pratica ciò significa che creerai due interfacce, ad esempio DataImportIf e DataImportIfInternal , dove l'altra interfaccia esporrà i metodi oi campi privati rilevanti e verrà utilizzata dal solo tester o dalle classi che costituiscono essi stessi parte dello stato DataImport .

risposta data 25.04.2014 - 17:31

fonte

Leggi altre domande sui tag tdd java

Definire un oggetto con l'interfaccia come tipo invece del nome della classe [duplicato] Dove inserire il dominio in MVCS

score 2 · Accepted Answer

Non eseguire alcuna elaborazione nel metodo fromStream() , basta chiamare un altro metodo - qualcosa come procesStreamResult() che viene chiamato ogni volta che qualcosa entra dallo stream. In questo modo, puoi testare procesStreamResult() chiamandolo con gli oggetti mock come argomenti e implementare anche la corretta gestione degli errori e il test delle unità.

Quello che sostanzialmente sto cercando di dire è: disaccoppiare la reale dipendenza esterna (lo stream, nel tuo caso) dal funzionamento interno del tuo codice e solo testare il codice che devi testare.