JUnit Best Practice: Fixtures diversi per ogni @Test

Question

Capisco che ci sono @Before e @BeforeClass, che vengono utilizzati per definire i dispositivi per il @Test. Ma cosa dovrei usare se ho bisogno di apparecchi diversi per ogni @Test?

• Devo definire l'apparecchio della @Test?
• Devo creare una classe di prova per ogni @Test?

Sto chiedendo le migliori pratiche qui, poiché entrambe le soluzioni non sono pulite secondo me. Con la prima soluzione, testerei il codice di inizializzazione. E con la seconda soluzione vorrei rompere il modello "una classe di test per ogni classe".

Answer 1

Punte:

1. dimenticare la classe di un test per ogni modello di classe, ha poco merito. Passa a una classe di test per prospettiva di utilizzo. In una prospettiva potresti avere più casi: limite superiore, limite inferiore, ecc. Crea diversi test @ per quelli della stessa classe.
2. Ricorda che JUnit creerà un'istanza della classe di test per ogni @Test, quindi ogni test otterrà un fix distinto (impostato dagli stessi metodi @Before). Se hai bisogno di un faro diverso hai bisogno di una classe di test diversa, perché sei in una prospettiva diversa (vedi 1.)
3. Non c'è niente di sbagliato nel modificare l'apparecchio per un particolare test, ma dovresti cercare di mantenere pulito il test quindi racconta una storia. Questa storia dovrebbe essere particolarmente chiara quando il test fallisce, quindi il diverso, ben chiamato @Test per ogni caso (vedi 1.)

Answer 2

Vorrei suggerire di creare una classe separata in base ai diversi dispositivi necessari. Se hai due proiettori diversi, devi semplicemente creare due classi diverse (dai loro un nome conveniente). Ma ci penserei una seconda volta su questo, in particolare sulla differenza tra i dispositivi e perché sono diversi. Potresti essere sulla strada per una sorta di test di integrazione invece di unit test?

Answer 3

Se si è certi che il dispositivo è unico per il test singolo, appartiene al metodo @Test. Questo non è tipico però. Potrebbe essere che una parte di essa sia unica o non sia stata parametrizzata/estratta correttamente, ma in genere condividerai molti degli stessi dati tra i test.

L'apparecchio finale è parte del test. Sistemazione apparecchio in @Before è stato adottato il modello xUnit perché i test sempre:

1. preparare dati di test/deride
2. eseguire operazioni con SUT
3. validate asserire stato/comportamento
4. distruggere i dati/test/deride

e passaggi 1 (@Before) e 4 (@After) vengono riutilizzati molto (almeno parzialmente) nei test correlati. Poiché xUnit è molto serio sull'indipendenza del test, offre metodi di verifica per garantire che eseguano e testano sempre i dati creati/distrutti correttamente.