Test-Data statici nella classe Helper: Getter vs Public Constant

Question

Test-Data statici nella classe Helper: Getter vs Public Constant

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

2

Attualmente sono in procinto di scrivere grandi lotti di Test unitari nel Progetto su cui sto lavorando. Inoltre abbiamo introdotto di recente il test della GUI. Questo progetto è una webapp relativamente semplice, basata su Java EE 6.

Ora il mio collega ha scritto un bel po 'di GuiTest, e ho scritto un bel po' di test unitari.

Per entrambi i test abbiamo bisogno di dati per eseguirli. Ora entrambi abbiamo adottato approcci diversi su come "memorizziamo" i dati che usiamo.

Soluzione 1:

public class UnitTestData {
     public static final String DATA_PIECE = "some data";
     public static final String MORE_DATA = "and more data";
     //... and so on
}

Soluzione 2:

public class GuiTestData {
    public String getDataPiece() {
        return "some data";
    }

    public String getMoreData() {
        return "and more data";
    }
    //... and so on.
}

La mia domanda ora è: quale di questi approcci è il migliore oggettivamente ?

testing design java data

posta Vogel612 04.09.2014 - 15:03

fonte

2 risposte

0

Secondo me, la soluzione dipende dalla complessità del tuo ambiente di test.

La soluzione n. 1 sembra più semplice e puoi usare l'importazione statica per semplificarla ancora di più in questo modo segui principio bacio Anche la soluzione numero 1 funziona meglio, poiché non è necessario creare un'altra chiamata allo stack sul thread che ha luogo nella soluzione n. 2.

Tuttavia, la soluzione n. 2 sembra funzionare meglio in scenari di test più avanzati quando si devono testare insiemi di dati. In questo caso dovresti esternalizzare un'interfaccia, ad es. GuiDataSource che GuiTestData avrebbe dovuto implementare per creare più implementazioni simili a GuiTestData e iniettarle su runtime durante la fase di test. Puoi anche prendere in giro facilmente tutto nella soluzione n. 2 e usare le riflessioni per fare un sacco di magia.

risposta data 04.09.2014 - 16:41

fonte

Leggi altre domande sui tag testing design java data

Come gestire la sicurezza di questi web apis auto-ospitati, per garantire che la richiesta di accesso ai dati venga autenticata? È giusto brevettare soluzioni alternative? [chiuso]

score 2 · Accepted Answer

Ci sono due argomenti per usare i metodi accessor invece delle variabili pubbliche:

Controllo di accesso : un metodo ci consente di pubblicare solo un metodo getter o di aggiungere vincoli basati sul valore (al contrario di tipo) su un setter. Con public final identificatori, questo punto è irrilevante, in quanto tale valore non può essere modificato e pertanto gli invarianti non possono essere interrotti dal codice client.
Accesso uniforme : il metodo di accesso ai dati in un oggetto non dovrebbe perdere informazioni sul fatto che questi dati siano archiviati o calcolati al volo. Nelle lingue senza "proprietà", come Java, ciò significa che tutti i dati dovrebbero essere accessibili tramite metodi e che nessuna variabile dovrebbe mai essere public . Ma perché il Principio di accesso uniforme esiste in primo luogo? Ha lo scopo di riservare margine di manovra per reimplementare le parti interne di un oggetto senza modificare l'interfaccia pubblica, in modo che il codice client che utilizza quell'oggetto non si rompa.

Ma nella tua situazione non esiste un codice client che utilizza un'API pubblica, stai solo memorizzando i dati per i test. Poiché non esiste alcuna API da mantenere, la giustificazione per l'UAP si riduce (anche se seguirla offre comunque tutti i vantaggi).

Quindi non ci sono argomenti convincenti per l'utilizzo di entrambe le soluzioni. È un campo piuttosto carino, e puoi scegliere liberamente.

Si noti che l'utilizzo dei metodi è assolutamente necessario quando ogni accesso deve restituire una nuova istanza. Questo è irrilevante per oggetti immutabili come le stringhe. Altrimenti, dovresti prendere in considerazione l'accesso a tutti i dati dei test tramite metodi di coerenza.

La mia opinione personale sarebbe quella di scegliere la cosa più semplice possibile, che userebbe public final variabili. Tuttavia, si prega di utilizzare le variabili membro e non static , in modo che i test possano passare i dati di test intorno come un oggetto di prima classe. (So che puoi accedere ai dati statici tramite le istanze, ma ritengo che sia un anti-pattern).

Se nel tuo team ci sono persone che non hanno familiarità con Java, potrebbe essere meglio memorizzare i dati di test in un file di configurazione (consiglio il formato YAML). Invece di scrivere la tua classe, dovresti utilizzare il parser dei file di configurazione per accedere ai dati.