Esiste un motivo valido per separare le aspettative dai test?

Question

Esiste un motivo valido per separare le aspettative dai test?

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

3

Ho ereditato un'applicazione che ha una serie di test che mi fanno impazzire. Ma una delle decisioni di progettazione che questa suite di test prende completamente mi lascia grattarmi la testa è la separazione dei test e le loro aspettative in file separati.

Per spiegare, ci sono test funzionali che hanno metodi di prova con decoratori. I test stessi eseguono il setup, eseguono la procedura di test e ogni eventuale demolizione, se necessario. Ma le aspettative per i test sono definite in file JSON o YAML separati. I decoratori sui metodi di prova fanno un po 'di magia per trovare il file delle aspettative e il set di dati appropriato per abbinare il metodo di prova.

Questo modello è anche usato per valori di input e fixture. Trovo che questo sia eccessivamente progettato, ma posso forse capire i valori di input e gli apparecchi esterni.

Questo mi fa impazzire perché se devo apportare una modifica logica, devo cercare tra più file per trovare i valori attesi e cambiarli. Ho sprecato giorni a cercare di sistemare la suite di test dopo che è stato effettuato un refactoring importante.

Voglio solo sapere se c'è un motivo valido per questo modello di progettazione. Non riesco a pensare a uno. Se qualcuno ha suggerimenti o informazioni sul motivo per cui questo modello è stato scelto o eventualmente prescritto, si prega di aggiungere collegamenti ad articoli, documenti e opinioni appropriati.

testing anti-patterns functional-testing

posta salvobeta 21.11.2017 - 10:58

fonte

4 risposte

Leggi altre domande sui tag testing anti-patterns functional-testing

Perché il fascino di Scala con la mappa piatta? (Questo non sembra essere lo stesso per mapcat nel mondo Clojure) [chiuso] L'ID dovrebbe essere indicato nell'URL se già protetto con ID JWT?

score 5 · Answer 1

Dalla tua descrizione, non esiste un motivo plausibile per mantenere le azioni e i risultati attesi che separano.

L'esportazione di dati in file di risorse esterne ha senso se esiste un'alta probabilità che i dati debbano cambiare spesso senza modificare il codice di elaborazione . Ad esempio, questo può fare la differenza tra dover eseguire una ridistribuzione costosa e una modifica semplice + forse un riavvio.

Ma questo riguarda i dati che vengono riassemblati dal computer. Una suite di test viene elaborata sia dai computer che dall'uomo ed è importante che il manutentore della suite di test possa facilmente correlare condizioni e risultati per capire cosa sta succedendo. Separarli senza il supporto degli strumenti per rimontarli sembra una decisione pessima. Non riesco a pensare a nessun beneficio di compensazione per giustificare questo. Non è come se i risultati attesi per un test dovessero cambiare molto spesso.

score 1 · Answer 2

Sì, potrebbe esserci una ragione valida. Non dire questo è il caso qui, solo che è possibile.

Separare le aspettative in formati di file dichiarativi separati dal codice di test consentirebbe a un non sviluppatore (come un analista aziendale) di scrivere test di logica aziendale. Questo potrebbe essere utile per i test di accettazione.

score 1 · Answer 3

Sì, c'è: BDD .

I sostenitori del BDD credono che questo vada bene:

First the product owner and tester produce a simple scenario file describing behavior and expectations.

Given a data fixture When a page is created with 20 items on a page Then expected lines on a page is 4 with data items in a line 5

Next developers write a harness and flesh out the steps required to meet the behavior.

Controlla la cronologia dei file dell'autore, probabilmente sarà un (precedente) proprietario del prodotto.

Potresti fare gruppo con il tuo team e cambiare tutti i test di stile "comportamentali" in uno stile diverso di test di integrazione alla volta.

score 0 · Answer 4

Scrivere un codice di prova in un senso molto reale è come scrivere il codice dell'applicazione in quell'organizzazione e riutilizzare il codice è la migliore pratica. Tuttavia, tendo ad essere d'accordo con te sul fatto che voglio essere in grado di leggere un metodo di prova e sapere esattamente cosa sta facendo. L'unica eccezione è l'installazione e la rimozione e solo se l'installazione e la rimozione eseguono attività che potrebbero essere comuni a tutti i test senza interferire con il test stesso (installazione e chiusura della connessione del database, ad esempio).

Quindi con questa logica, tendo a creare classi helper chiare e concise con metodi statici che organizzino le attività che devono essere eseguite per un test in pochissime chiamate. In altre parole, invece di dover cercare il file di test per capire cosa viene testato, posso vedere chiaramente il codice come:

User john = TestUserHelper.createUser("JOHN SMITH");

// The test
john.changePermissions(ADMIN);

john = TestUserHelper.loadUser("JOHN SMITH");

assertEquals(ADMIN, john.getPermissions());

Chiaramente c'è molto da fare sotto, ma è semplice da leggere ed è facile da cambiare. La maggior parte del lavoro svolto viene eseguito in TestUserHelper . Penso che questo sia qualcosa per cui sforzarsi francamente. E sì, dal momento che scrivere codice di prova è molto simile alla scrittura del codice dell'applicazione, anche in questo caso è una cosa da perseguire. Nascondere la complessità a volte serve solo a nasconderlo, non a ridurlo.