Domanda

Sto cercando di setacciare la miriade di soluzioni di prova là fuori e non sono nemmeno sicuro di essere diretto nella giusta direzione. La storia è: stiamo eseguendo un servizio Web RESTful, implementato come app Rails, che sostiene i nostri clienti mobili. Stiamo testando unità il servizio Web (ovviamente), ma ciò implica deridere molte parti dell'applicazione, ad esempio, lo stack di ricerca (Apache Solr).

Inoltre, i nostri test non (cioè non possono!) Coprono i percorsi critici come il processo di accesso/accesso mobile, poiché ciò comporta la comunicazione tra l'applicazione API e il sito Web mobile, in cui l'utente può inserire credenziali, ad esempio per SSO (Janrain Engage). Quindi, un test di integrazione delle rotaie standard non lo farà.

Mi rendo conto che in teoria, se la suite di test è molto ben progettata, in cui il beffardo si verifica solo rigorosamente in quei punti di join in cui i test per il livello successivo iniziano, quindi mediante unità o test funzionale l'API di servizio e il sito Web mobile separatamente, uno potrebbe ottenere la stessa copertura del test. Trovo che, in pratica, questa è un'illusione se hai diversi sviluppatori che lavorano sulla suite di test in modo indipendente; Ammetto solo che i nostri test unitari non sono semplicemente ben progettati. Soprattutto quando esercitavo TDD ho scoperto che mentre i test possono guidare il codice dell'applicazione, la progettazione del codice di prova è su misura per l'unità in test, risultando in una suite di test piuttosto selvaggiamente coltivata.

Un'altra cosa che ho scoperto è che a volte non abbiamo rilevato le regressioni utilizzando esclusivamente test unitari, in cui sono state inviate domande negative ad es. Solr a causa di effetti a catena. Ecco perché ho pensato che l'unico vero modo per garantire che l'intero stack funzioni lungo i percorsi critici fosse quello di testarlo automaticamente su un server di gestione temporanea prima di ogni distribuzione, cioè avere richieste HTTP effettive inviate all'app.

Le mie domande sarebbero:

  • Pensi che questa sia una cosa ragionevole da fare? Ho trovato pochissime informazioni sul test end-to-end di un'API dal vivo sul web, lasciandomi chiedermi se ho un senso
  • Quali strumenti/configurazione suggeriresti? Usiamo WATIR per eseguire test di accettazione per il nostro sito Web, ma sembra essere eccessivo per un servizio Web (nessun ambiente browser necessario, nessun JS o niente di Ui-ish). Qualcosa di semplice come una sceneggiatura di Ruby?
  • Qualche best practice o consigli generali che puoi darmi WRT alla progettazione di tali test?
È stato utile?

Soluzione

Questo potrebbe essere interessante per te: http://groups.google.com/group/ruby-capybara/browse_thread/thread/5c27bf866eb7fad3

Quello che potresti voler provare è combinare cetriolo (o simile) con uno degli strumenti menzionati nel link sopra, quindi puoi fare qualcosa di simile

Given I have 2 posts
When I send "DELETE" to post with id 1
Then I should have 1 post

In questo modo puoi testare lo stack completo dell'API e controllare il risultato.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top