Come sapere cosa testare in TDD? [duplicare]

5

Ho sentito parlare di TDD più di un anno fa, ma fino ad ora non sono riuscito a farmi iniziare. In effetti, uno dei miei più grandi dubbi è sempre cosa testare. Gli esempi forniti mostrano sempre test per verificare se alcune regole aziendali sono state implementate correttamente.

Quindi, ad esempio, in un software di aste abbiamo la regola aziendale "un utente può pubblicare un'offerta su un articolo solo se il valore è maggiore del valore dell'ultima offerta". Va bene, questo tipo di cose è facile immaginare che dobbiamo assicurarci di lavorare. Queste sono le cose a cui sarebbe utile l'utente finale del sistema.

Ma a volte stiamo lavorando sull'infrastruttura del sistema. Autenticazione e autorizzazione, selezione delle risorse per gli utenti, verifiche di sicurezza e così via. In questi casi non sembra ovvio in primo luogo cosa dovremmo testare.

Quindi, al momento non sto ancora usando TDD perché sempre quando penso di farlo mi trovo a chiedere "ok, ora quali test dovrei scrivere" e non ho mai ora di rispondere a questa domanda. Come posso sapere quali test dovrei scrivere quando inizi a creare un'applicazione?

    
posta user1620696 26.04.2014 - 04:37
fonte

2 risposte

8

Guarda, il tuo software deve fare qualcosa altrimenti non lo scriverei. "Ho bisogno di qualcosa per verificare le credenziali delle persone". È un requisito di alto livello perfettamente preciso per iniziare a fare test da.

Il TDD è al centro di una struttura in cui puoi chiedere "cosa farà questa cosa?". Vuoi autenticare e autorizzare gli utenti? Grande. Ora scrivi il tuo codice ideale che autentica e autorizza gli utenti (sotto forma di test). Questo ti permette di definire effettivamente cosa il tuo codice ha bisogno di fare, così come una bella interfaccia per qualcuno da usare (dato che hai iniziato ad usarlo). Realizzare il codice di lavoro effettivo per colmare le lacune è l'ultimo perché per quasi tutto il codice l'interfaccia è più importante dell'implementazione.

Cosa testare è semplicemente che stai cercando di implementare piuttosto che come intendi implementarlo. Se non sai nemmeno cosa stai cercando di realizzare, forse dovresti smettere di scrivere il codice e scoprirlo prima.

    
risposta data 26.04.2014 - 05:04
fonte
5

Il motivo per cui penso che tu abbia fatto una grande domanda qui è che hai davvero individuato il principale impedimento di scavare nel TDD - che cosa testerai successivamente? Rispondere a questa domanda è molto più semplice con un semplice alcune nozioni chiare nella tua testa.

(1) TDD, contrariamente al nome, è non sui test.

“Folks who do TDD for a while typically come to the conclusion that the only thing that TDD has to do with testing is the appearance of the word test in its name. That’s a bit of an exaggeration, but it’s a common one used by TDD’ers to help clarify the issue. We use unit testing frameworks to do TDD, and we write the example code in methods that can be executed by the test runners that come with unit testing frameworks, but that’s about the end of the commonalities between TDD and testing.” ― Scott Bellware, Behavior-Driven Development

(2) L'obiettivo di TDD è non di venire fuori con i test; è di venire con specifiche (o comportamenti).

“The entities we write are not actually tests. They are specifications. What we are doing is replacing traditional specs with automated specs. The process of writing the specification is an analysis task, one that leaves behind a suite of tests as a side-effect artifact...” ― Scott Bain, Overcoming Impediments to TDD

(3) Per determinare cosa testare successivamente (o anche da dove iniziare) la domanda semplifica in: Qual è la prossima cosa più importante che il sistema non fa ancora? (Lasciatemi toccare esplicitamente un punto implicito nella risposta di Telastyn: la tua domanda suggerisce che stai cercando di allineare i test unitari con le storie degli utenti, ma esistono a diversi livelli nella gerarchia architettonica. più vicino all'implementazione, molto più a grana fine.) Quindi la "prossima cosa più importante" si riferisce alla cosa implementabile, non alla realtà a livello di utente.

(4) La risposta alla domanda in (3) dovrebbe essere un comportamento B . Scrivi questo comportamento B come frase S 0 . Se la frase è troppo lunga o complessa, dividerla in più frasi S 0 , S 1 , S 2 ...

Ogni frase simile S n nomina un test.

Quindi, con queste semplici idee in mente, non solo riesci a capire cosa testare, ma anche il nome del metodo di prova ti lascia ... con "solo" l'implementazione da fare.

    
risposta data 27.04.2014 - 18:24
fonte

Leggi altre domande sui tag