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.