Test funzionali e test di accettazione che portano al codice ridondante

Question

Test funzionali e test di accettazione che portano al codice ridondante

#1 da (6 voti)
#2 da (1 voti)

6

Quello che so è:

Un test funzionale mira a testare un singolo componente (come un controller WebApp) dal punto di vista dello sviluppatore . = > Ho raggiunto tutti i requisiti per farlo funzionare bene?
Un test di accettazione mira a testare un gruppo di componenti insieme e si concentra sul punto di vista del business. = > Il mio programma soddisfa i requisiti forniti dal Cliente / Azienda / Cliente?

Oggi, lavoro su un progetto personale e ho iniziato a seguire i metodi BDD / test e ho quindi creato test di accettazione e test funzionali.

Ho notato che molti requisiti per i test funzionali sono esattamente gli stessi dei test di accettazione.

Supponiamo che un controller webapp tenti di aggiungere un prodotto al paniere del mio e-commerce.

Uno dei test funzionali interessati sarebbe:

When I go to productList.html page and I call the addProductToBasket action, I expect my controller to retrieve the right quantity and the right product name, and expect my view to display it. (very generic)

Sicuramente, Business si aspetta che l'applicazione si comporti nello stesso modo in cui uno sviluppatore aveva scritto in alcuni dei suoi test funzionali, quindi in questo caso, un test di accettazione sarebbe:

Given Bob enters in the product list page, when he clicks on the button "addToBasket" near to the "Nike basket n°2" product, basket should display quantity '1' and "Nike basket n°2". (specification by example)

Entrambi i test sono molto simili, vero?

Quindi la mia domanda è: rischiamo di creare un sacco di codice di duplicazione e test ridondanti durante la creazione di test funzionali e di accettazione in parallelo?

Che cos'è una buona pratica? Fare test funzionali portano solo cose puramente tecniche, come comportamenti eccezionali / buggy, scenari variabili incoerenti, ecc ... e lasciare che i test di accettazione si occupino dell'intero scenario degli scenari di business?

Direi anche: I test funzionali sono davvero necessari quando attribuiamo una grande importanza al test di accettazione?

tdd bdd testing acceptance-testing functional-testing

posta Mik378 21.02.2013 - 02:57

fonte

2 risposte

1

Sì, i test dovrebbero esistere a più livelli, in più moduli e sì, vedrete molta ridondanza.

Ad esempio in un MVC è possibile avere un test in tutte e tre le posizioni che controllano il valore di un attributo. Questo può essere visto come una cosa positiva perché allora puoi cambiare qualsiasi pezzo e conoscere l'effetto del cambiamento.

Quindi sì, come hai detto i diversi test dovrebbero testare cose diverse. I test di database possono eseguire operazioni CRUD e controllare i risultati, il middleware può essere testato in modo simile e può essere utilizzato per guidare lo sviluppo (TDD).

I test front-end possono garantire che l'utente finisca per vedere i risultati desiderati, indipendentemente dai capricci dei dispositivi di output e delle versioni.

risposta data 21.02.2013 - 03:19

fonte

Leggi altre domande sui tag tdd bdd testing acceptance-testing functional-testing

Qual è la convenzione per la posizione stellare nelle variabili di riferimento? Scenari per le differenze tra UICulture e Cultura

score 6 · Accepted Answer

Sì, può esserci una duplicazione. Spesso con la linea di siti Web di tipo business, i test di accettazione possono effettivamente sostituire i test orientati agli sviluppatori, poiché la profondità del codice necessaria per implementare le funzionalità non è eccessiva. A titolo di paragone, il software di riconoscimento delle immagini può avere un'enorme profondità, ma a un livello di accettazione potrebbe essere semplice come deve riconoscerlo come un cerchio, e questo come un quadrato. Per quanto riguarda gli sviluppatori, è necessario testare l'acquisizione delle immagini, la correzione della luce, il rilevamento degli oggetti, il riconoscimento degli oggetti, bla bla ....

Quindi, se disponi di una quantità ridotta di codice tra l'accettazione e l'implementazione, spesso ti sembra ridondante.

Tuttavia, ci sono alcune altre differenze in termini di processo. È possibile creare una serie di test di accettazione e non tutti devono passare tutto il tempo, possono agire come obiettivi, quindi passare dal 5% passato al 10% al 50% ecc. le prove fuori. In alcuni casi, idealmente questi test possono essere messi insieme semi indipendentemente dallo sviluppatore. Test orientati agli sviluppatori, l'intenzione è di farli passare tutto il tempo.