Sto costruendo un'applicazione web in php. Sto seguendo TDD (scrivi test prima del codice di produzione) per i miei test unitari e utilizzo BDD per guidare la scoperta delle funzionalità delle mie applicazioni e per fornire test di integrazione.
La mia architettura è basata su Robert Martins Clean Architecture dove per uso ho case case application / interattori che formano le classi principali della mia applicazione.
I miei passi BDD chiamano l'applicazione per usare le classi di casi direttamente per guidare l'applicazione. I test TDD vengono scritti prima di ogni nuova riga di codice e forniscono test unitari per tutte le classi. Con questi due metodi di sviluppo, ho una copertura completa del test della mia domanda di integrazione e test unitari.
Il problema a cui mi sono imbattuto è che mentre ho provato tutto nell'applicazione, e ho confermato che tutte le funzionalità richieste sono state implementate, quello che non ho è una bella interfaccia utente dell'applicazione Web che un utente può usare. Attualmente gli unici utenti che possono utilizzare l'applicazione sono gli sviluppatori che dovrebbero chiamare l'applicazione per utilizzare direttamente le classi di casi. Per gli sviluppatori, il codice base è coperto al 100% da unit test (TDD) e test di integrazione (BDD).
Quello che devo fare ora è creare un'applicazione browser che chiamerà gli URI. Questi URI saranno collegati ai casi d'uso dell'applicazione. Come qualsiasi applicazione browser moderna, l'applicazione browser chiamerà più URI in modo asincrono per fornire un'esperienza utente ricca.
La mia domanda è: come posso testare questa parte della mia base di codice? Questa non è una domanda su quale strumento usare (anche se le raccomandazioni sarebbero gradite), ma più a che livello dovrei testare? Immagino che questa domanda possa anche essere scritta come
"Sono uno sviluppatore front-end che crea un'app Web front-end utilizzando una libreria o un servizio Web creato da un altro sviluppatore. Come dovrei testare la mia app? '
I miei due pensieri sono:
- Verifica l'applicazione del browser e gli URI associati, ma prendi in giro i casi di utilizzo delle applicazioni chiamati dai controllori
- Lascia che i controller chiamino i casi d'uso reali dell'applicazione e forniscano in effetti un altro livello di test di integrazione / test end-to-end con l'aggiunta del livello di consegna Web (applicazione browser e URI)
Il problema che vedo con 1) (come in tutti i test in cui sono coinvolti i mock) è che se io simulo in modo errato le richieste e le risposte per i casi d'uso di quella applicazione, non ci saranno test da raccogliere e verranno visualizzati i bug una volta che tutto è integrato insieme.
Questo porta quindi alla ovvia risposta che dovremmo testare con maggiore integrazione usando 2). Il problema che ho con questo è che sento che ora sto duplicando molti test di integrazione e il test sarà molto lento.
Im anche non sono sicuro di quale livello di test dovrei scrivere. Devo scrivere un test di accettazione per utenti di grandi dimensioni che prende insieme un numero di casi d'uso diversi? per esempio. verificare che un prodotto possa essere aggiunto a un negozio, acquistato da un cliente e quindi spedito. O dovrei testare ciascuna vista dell'interfaccia utente da sola? per esempio. il cliente può visualizzare il prodotto per l'acquisto.