Test case come funzione o test case come una classe

In passato, un caso di test si riferiva di solito a una funzione / metodo. Tuttavia, ai nostri giorni, un Test Case di solito si riferisce a un "Test", che indica una classe contenente un insieme di metodi strongmente correlati l'uno all'altro da un punto di vista del test.

I metodi in queste classi di casi di test sono chiamati metodi di prova.

Considerando questo, l'inclusione sarebbe. Metodo di prova (testare una singola cosa specifica - stato o comportamento) fa parte di un caso di test (che si riferisce probabilmente a una funzionalità o sottomodulo) che a sua volta fa parte di una Test Suite (che si riferisce a un gruppo di casi di test e può essere organizzato come desideri).

Per ulteriori informazioni su queste strutture e sull'organizzazione di test in generale, ti raccomando xTest di test di identità: codice del test di refactoring di Gerard Meszaros

La seguente è la mia opinione:

Vantaggi della scrittura di test come funzioni:

• Se hai bisogno di prerequisiti per quel caso, chiama semplicemente un'altra funzione che fornisce i prerequisiti. Fai la stessa cosa per i passaggi di rimozione
• Sembra semplice per una nuova persona nel team. Facile da capire cosa succede esaminando i test come funzioni

Contro la scrittura di test come funzioni:

• Non gestibile - Perché se ci sono un numero enorme di test dove lo stesso tipo di prerequisiti è richiesto, l'autore del caso di test deve farlo continuare a chiamare ogni funzione pre-requisito nel caso di test. Stesso per ogni teardown all'interno del test case

• Se ci sono così tante chiamate a tale funzione pre-requisito all'interno di molti casi di test, e se qualcosa cambia nella funzionalità del prodotto, ecc, devi sforzarti manualmente in molti posti di nuovo.

Professionisti della scrittura di casi di test come classi:

• Setup, run e teardown sono chiaramente definiti. i prerequisiti del test sono facilmente comprensibili
• Se c'è il Test 1 che fa qualcosa e il risultato del Test 1 è usato come prerequisito di installazione nei Test 2 e 3, è facile ereditare dal Test 1 e chiamare il suo setup, eseguire un metodo di rimozione prima, e poi, continua i tuoi test. Questo aiuta a rendere i test indipendenti l'uno dall'altro. Qui, non è necessario fare sforzi per mantenere l'effettiva chiamata del codice. Sarà fatto implicitamente a causa dell'eredità.
• A volte, se il metodo di installazione di Test 1 e il metodo di esecuzione di Test 2 potrebbero diventare i prerequisiti di un altro Test 3. In tal caso, ereditare solo da entrambe le classi Test 1 e Test 2 e nella configurazione di Test 3 metodo, chiamare l'installazione di Test 1 ed eseguire il test 2. Di nuovo, non è necessario mantenere la chiamata del codice effettivo, perché si stanno chiamando i metodi di installazione ed esecuzione, che sono provati e testati dal punto di vista del framework. / li>

Contro la scrittura del caso di test come classi:

• Quando il numero di test aumenta, non puoi esaminare un determinato test e dire cosa fa, perché potrebbe aver ereditato così tanti livelli che non puoi più tenere traccia. Ma c'è una soluzione intorno ad esso - Scrivi stringhe doc in ogni configurazione, esecuzione, metodo di smontaggio di ogni caso di test . E, scrivi un wrapper personalizzato per generare stringhe doc per ogni caso di test. Mentre / Dopo l'ereditarietà, è necessario fornire un'opzione per aggiungere / Rimuovere la docstring di una particolare funzione (setup, run, teardown) alla funzione ereditata. In questo modo, puoi semplicemente eseguire quel wrapper e ottenere informazioni su un caso di test dalle sue stringhe di documenti

Preferisco Testcase come classe perché

• In Untitests hai di solito diversi test con un contesto simile che sarebbe logicamente raggruppato da una classe.
• In Integration e System-Tests hai di solito un tipo di variabili globali che vengono aggiornate / verificate nei passaggi del test. Se queste variabili globali non sono membri di una classe, non è possibile eseguire più test contemporaneamente (per prestazioni o stress test) perché i test si influenzano a vicenda.

In realtà non vedo alcun vantaggio di un metodo di prova non di classe.