Ho capito correttamente il termine Honeycomb?

1

In seguito alla mia domanda precedente e ai commenti sotto la risposta accettata: Un progetto di test di accettazione per strato o un progetto di test di accettazione per contesti limitati

Recentemente ho letto molto sul BDD mentre cerco di decidere se è applicabile a un progetto. Ho trovato il termine Honeycomb ( link ), che sembra suggerire che "end to end" può significare cose diverse a seconda che tu sia interessato alla velocità o all'affidabilità. In un caso può significare l'interfaccia utente (la maggior parte del livello esterno) per il modello di dominio (la maggior parte del livello interno) e in un altro caso può significare solo il modello di dominio da solo. Non riesco a trovare ulteriori informazioni su Honeycomb.

Ho capito "end to end" correttamente? Il mio team sta attualmente sviluppando un modello di dominio per un'applicazione. Non scriveremo gli altri livelli, ad es. servizio applicativo; Interfaccia utente ecc. È normale utilizzare BDD per testare un livello dell'applicazione in isolamento? In questo caso, da un capo all'altro, dal modello di dominio al modello di dominio piuttosto che dall'interfaccia utente al modello di dominio.

Il motivo per cui lo chiedo è perché credo che ci aiuterà a coinvolgere gli analisti di business e il controllo qualità. Tuttavia, non voglio abusare di BDD.

    
posta w0051977 11.03.2018 - 20:42
fonte

1 risposta

4

C'è molta sfocatura nei termini test unitario, test di integrazione e test end-to-end. Alcuni pensano che si sovrappongano e siano intercambiabili. In una certa misura questo è vero.

Una fonte importante di confusione arriva quando le persone accoppiano i termini a come sono stati implementati. Questo è sbagliato. Non tutti i test che scrivi utilizzando jUnit, o alcuni di questi, sono un test unitario. L'utilizzo di un particolare framework o stile di codifica non lo rende un certo tipo di test. Si tratta di ciò che si prova. E in larga misura, in che modo esegui il test esegue .

Itestunitaripossonoessereatomici.Quelloèchetestanolapiùpiccolacosapossibiledatestare.Alcunepersoneusanosolol'unitàperindicarel'atomico.Ilchevabene,ma altri imposta il limite alla velocità. Hanno requisiti prestazionali che insistono nel conformarsi a tutti i loro test unitari. Personalmente mi piace questa seconda ripresa del significato del test unitario.

I test di integrazione sembrano sovrapporsi a questa seconda idea di cosa sia un test unitario. Dopo tutto, se sono coinvolte due cose atomiche, devono integrarsi in qualche modo. Altri vedono test di integrazione come accadono attraverso i confini architettonici. Questi test non hanno gli stessi limiti di prestazioni dei test unitari. Di nuovo sono al secondo campo.

I test end-to-end in quasi tutti i casi in cui li ho vissuti riguardano l'utilizzo di un caso d'uso dall'inizio alla fine. Ancora una volta si sovrappone, almeno in parte, alla definizione di un test di integrazione. Non deve coinvolgere un'interfaccia utente poiché potrebbe non esistere ma potrebbe. Soprattutto se stai facendo test manuali. Test automatici che coinvolgono un'interfaccia utente sono notoriamente difficili, soprattutto perché le UI sono molto soggette a cambiamenti. Una buona pratica è rimuovere tutta la logica testabile dall'interfaccia utente in modo che i test automatizzati possano guidare l'applicazione attraverso l'API utilizzata dall'interfaccia utente come se fosse l'interfaccia utente.

Qui ci sono mentalità concorrenti che provocano le diverse interpretazioni. Non mi piace l'idea che gli strumenti che uso dettano ciò che sto facendo. Non mi piace l'idea che la struttura in questione dettami ciò che sto facendo. Mi piace distinguere ciò che sto facendo in base alle esigenze che sto realizzando. Uno di questi è la velocità.

Si spera che il modo di definire questi termini si aggiri.

    
risposta data 11.03.2018 - 21:23
fonte

Leggi altre domande sui tag