Come puoi TDD per un bug che può essere testato solo dopo che è stato corretto?

13

Ecco un esempio: la mia applicazione web contiene elementi trascinabili. Quando si trascina un elemento, il browser produce una "immagine fantasma". Voglio rimuovere l'immagine "fantasma" durante il trascinamento e scrivo un test per questo comportamento.

Il mio problema è che inizialmente non ho idea di come correggere questo bug e l'unico modo per scrivere un test è dopo che l'ho risolto.

In una semplice funzione come let sum = (a, b) => a - b , puoi scrivere un test sul motivo per cui sum(1, 2) non è uguale a 3 prima di scrivere qualsiasi codice.

Nel caso che sto descrivendo, non posso testare, perché non so quale sia la verifica (non so quale dovrebbe essere l'asserzione).

Una soluzione al problema descritto è:

let dataTransfer = e.dataTransfer
let canvas = document.createElement('canvas');
canvas.style.opacity = '0';
canvas.style.position = 'absolute';
canvas.style.top = '-1000px';
dataTransfer.effectAllowed = 'none';

document.body.appendChild(canvas);
dataTransfer.setDragImage(canvas, 0, 0);

Non potevo sapere che questa era la soluzione. Non avrei nemmeno potuto scrivere il test dopo aver trovato la soluzione online, perché l'unico modo in cui avrei potuto sapere se funzionasse davvero, era aggiungere questo codice nella mia base di codice e verificare con il browser se avesse avuto l'effetto desiderato. Il test doveva essere scritto dopo il codice, che va contro TDD.

Quale sarebbe l'approccio TDD a questo problema? Il test è scritto prima del codice obbligatorio o facoltativo?

    
posta maximedupre 23.05.2018 - 23:01
fonte

4 risposte

24

Quando ho capito bene, non puoi nemmeno scrivere un test automatico affidabile per il tuo esempio di "immagine fantasma" dopo hai trovato una soluzione, dal momento che l'unico modo per verificare il comportamento corretto è guardare lo schermo e controlla se non ci sono più immagini fantasma. Questo mi dà l'impressione che il titolo originale abbia fatto la domanda sbagliata. La vera domanda dovrebbe essere

  • come testare automaticamente un determinato comportamento di un'interfaccia utente grafica?

E la risposta è - per diversi tipi di problemi dell'interfaccia utente, non . Certo, si può provare ad automatizzare rendendo l'interfaccia utente che mostra il problema in qualche modo, e cercare di implementare qualcosa come un confronto di screenshot, ma questo è spesso soggetto a errori, fragile e non conveniente.

Soprattutto "testare" l'interfaccia utente o i miglioramenti dell'interfaccia utente con test automatici scritti in anticipo sono letteralmente impossibili. Tu "guidi" la progettazione dell'interfaccia utente apportando un miglioramento, mostra il risultato a un umano (te stesso, alcuni tester o un utente) e chiedi feedback.

Quindi accetta il fatto che TDD non è un proiettile d'argento, e per alcuni tipi di problemi il test manuale ha ancora più senso dei test automatici. Se hai un processo di test sistematico, magari con alcuni tester dedicati, la cosa migliore che puoi fare è aggiungere il caso al loro piano di test.

    
risposta data 23.05.2018 - 23:25
fonte
3

What would be the TDD approach to this problem? Is writing the test before the code mandatory or optional?

Un modo è applicare un analogo di una soluzione per spike .

James Shore l'ha descritto in questo modo:

We perform small, isolated experiments when we need more information.

L'idea di base è di mettere giù gli strumenti design mentre stai cercando di capire cosa sta succedendo. Una volta che hai i cuscinetti, riprendi gli strumenti di progettazione.

Il trucco: porti la conoscenza dalla tua indagine al codice di produzione, ma non porti il codice . Invece, lo si ricrea usando le tecniche di progettazione disciplinate.

Cavalli per i corsi.

EDIT:

How can you automate a test if the defect can only be seen by a human eye?

Vorrei suggerire un'ortografia leggermente diversa: "Come è possibile automatizzare un test se l'automazione del test non è economicamente vantaggiosa?"

La risposta, ovviamente, è "non lo fai". Piuttosto, cerca di separare la tua implementazione in due parti: una grande parte in cui il testing è conveniente e una parte più piccola che è troppo semplice da interrompere.

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies -- C.A.R. Hoare

Quindi quando lavoriamo con codice di terze parti, avremo una shell di codice molto sottile che funge da proxy per la libreria di terze parti. In test, sostituiamo quella shell con un "test double", che verifica il protocollo , senza preoccuparci che produca gli effetti desiderati.

Per testare l'integrazione dei nostri codici con il vero codice di terze parti, ci affidiamo ad altre tecniche (verifica visiva, chiamate al supporto tecnico, ottimismo ....)

Può essere utile mantenere alcuni artefatti di dimostrazione in giro, in modo che tu possa verificare che le tue ipotesi siano ancora valide quando aggiorni la libreria di terze parti.

    
risposta data 23.05.2018 - 23:28
fonte
0

Solo una prospettiva diversa, i test intorno all'interfaccia utente / GUI possono essere migliorati in qualche modo rispetto ai test di accettazione (test centrati sul flusso di lavoro / funzionalità).

Per il web, penso che framework come il selenio web abbiano il potenziale per avvicinarsi al test corretto, ma il sovraccarico per iniziare potrebbe essere un po 'troppo, ed è uno spostamento nel flusso visto con TDD rispetto a solo test unitari.

La parte che potrebbe aiutare in modo specifico con la tua situazione è qualcosa chiamato Page Object Model ( collegamento ). Ciò consente di ottenere una mappatura esplicita della GUI in fase di esecuzione su un determinato codice, assegnando nomi a metodi / eventi / membri della classe.

Gli argomenti principali contro questo sarebbe il sovraccarico, e che questo sovraccarico di solito potrebbe essere visto alla fine del ciclo per lo sviluppo. Il sovraccarico è che i test richiedono un wrapper che sembra creare un lavoro duplicato.

Andando avanti, dipenderebbe dal rapporto costi / benefici del team e degli affari, quindi potrebbe essere un argomento utile da discutere per determinare aspettative e punti di vista.

    
risposta data 24.05.2018 - 16:26
fonte
0

Che aspetto ha l'immagine di un fantasma? Se hai creato un UI fittizio di un colore noto, dove inserisci il tuo componente trascinabile? Ci sarebbe un colore specifico presente se ci fosse un'immagine fantasma.

Quindi il test potrebbe testare l'assenza del colore dell'immagine fantasma.

Un test del genere sarebbe ragionevole durevole e fattibile.

    
risposta data 24.05.2018 - 08:51
fonte

Leggi altre domande sui tag