Test di accettazione con dati precaricati o riempimento in movimento

2

Stiamo cercando di capire se dovremmo scrivere test di accettazione che ruotano attorno a dati precaricati su un file di database, o aggiungere programmaticamente i dati necessari per test o riempire il database mentre testiamo altre funzionalità delle applicazioni.

Questo è un caso più dettagliato e di facile utilizzo: desideri test di accettazione (o test dell'interfaccia utente) aggiungendo una Book al sistema. Ma per farlo, devi avere già Category di righe nel database, quindi puoi assegnarne una al libro. Mentre stai scrivendo il tuo test case per aggiungere un libro, tu:

  1. Utilizza un file di database seminato in precedenza che contiene già categorie in esso.

    • contro sarebbe necessario mantenere quel file con ogni modifica del codice, con le modifiche latest sul sistema, E dovresti riempirlo tenendo conto della logica di business aggiuntiva (ad esempio, potresti seminare autori con parametri casuali ; ma risulta che un autore non può essere selezionabile a meno che non superi le condizioni x, ye z e la seminatrice non ha tenuto conto di ciò)
  2. aggiungi la categoria nel test.

    • contro sarebbe necessario mantenere ancora una volta la logica di business aggiuntiva
  3. Ogni funzione testata conserva i dati , quindi per prima cosa esegui il test di accettazione per aggiungere categorie e quindi per aggiungere un libro.

    • contro sarebbe il tuo strumento di test non avrebbe bisogno di isolare i test, o almeno eseguirli in un certo ordine.

Forse c'è una quarta opzione che non ho ancora considerato? Qual è l'approccio corretto per questo compito comune?

    
posta Christopher Francisco 18.12.2015 - 21:40
fonte

2 risposte

1

Lo stiamo facendo in seconda battuta. Il migliore sarà mostrarlo con un esempio (python):

def test_that_we_can_add_book_to_library(self):
    category = Category('Fantasy')
    self.library.add_category(Category('Fantasy'))
    book = Book(Title('Hobbit'), category)
    self.library.add_book(book)
    self.library.has_book(book)

Ciò che è importante qui è un fatto che library è un oggetto creato solo per i test. Ha comportamenti che incapsulano la logica (che può cambiare) necessaria per i test. Addizionalmente rende il test più leggibile. library.add_category è un comportamento del genere, se qualcosa cambia nella logica aziendale relativa alla categoria, allora lo cambiamo solo lì.

library.has_book è un metodo di asserzione che controlla se il libro è stato aggiunto alla nostra memoria.

È molto ben descritto nel libro " Crescere software orientato agli oggetti: guidato da test ". Chiunque voglia scrivere buoni test dovrebbe leggerlo imho.

    
risposta data 18.12.2015 - 21:56
fonte
1

Preferisco fare entrambe le cose.

Conserva un piccolo database predefinito o una serie di proiettori che possono essere utilizzati per i test del fumo. Dovrebbe avere il minimo di dati - un singolo utente, una singola categoria, un singolo libro, ecc. Ciò ti consente di scrivere ed eseguire almeno alcuni test di base senza molto lavoro extra.

Quindi, per test più complessi, dovrebbero creare i dati di cui hanno bisogno al volo (e ripulirlo quando finito!).

Un'altra soluzione è iniziare con un database nullo e scrivere test che lo popolano con un nucleo di oggetti. Quindi il flusso di lavoro è:

  • supporto del nuovo database
  • esegui i test di installazione che popolano il database con i dati principali
  • se l'installazione ha esito positivo, esegui test aggiuntivi che possono utilizzare questi dati di configurazione iniziali, oltre a creare tutti i dati aggiuntivi di cui ha bisogno al volo.

Il vantaggio di questo secondo approccio è che si dispone di un singolo processo che può agire sia come test del fumo di parti dell'interfaccia utente o dell'API, e agire come una fase di installazione che prepara il database a test più estesi.

    
risposta data 18.12.2015 - 23:48
fonte

Leggi altre domande sui tag