Questo dipende da quale fedeltà è richiesta per il test. A volte può essere sufficiente testare su un livello di richieste HTTP simulate:
Given an API
When I POST /the-form with key=value
Then the response is {"some": "data", "key": "value"}
È adatto come test di integrazione per un'API o un back-end, ma probabilmente non per un modulo HTML. Per esempio. i campi potrebbero mancare.
Ottenete test di fedeltà superiore se utilizzate un framework di automazione che analizza l'HTML e ad es. ti permette di compilare moduli con il loro selettore o etichetta CSS e di interrogare i dati con selettori CSS.
Given I am on the page /the-form
When I fill out key with value
And submit the form
Then .datasheet > .key-value is value
And .datasheet > .title contains “your data has been processed successfully”
Per le pagine Web con molto JavaScript (ad esempio SPA) è necessario eseguire un browser reale. Il selenio aiuta lì. Ma questo livello di fedeltà potrebbe non essere richiesto per una tipica app Rails. Più realistici sono i test, più lentamente saranno in genere.
È normale che i casi di test contengano scenari concreti con dati di esempio che si verificano. Potresti considerare questo "hard-coding", ma esempi concreti sono molto più facili da capire rispetto alle fabbriche di set di dati astratti. Tuttavia, molti strumenti di test consentono di parametrizzare lo scenario su più set di dati di esempio.
Quando si eseguono questi scenari, il test dovrebbe essere chiaro su cosa sia il sistema in prova. Per i test basati su browser, è probabile che eseguiate test end-to-end del vostro sistema completo, senza alcun servizio esterno. E tu limiti i tuoi test per osservare ciò che un utente normale vedrebbe. Pertanto, non è necessario verificare che alcuni record siano stati creati nel database: l'esistenza e la struttura di un database sono dettagli di implementazione. Invece, verificherai che l'interfaccia web mostra i dati corretti dopo che è stata intrapresa un'azione.