Naming
Affrontiamo prima la denominazione. Unit_StateOrEvent_Behavior è una convenzione di denominazione ragionevole secondo me. Ricorda che un'unità non è necessariamente una classe.
I nomi dei test devono esprimere i requisiti che testano, non i nomi delle classi che implementano i requisiti. Questo vale anche per il nome della classe di test.
Normalmente non si ha una mappatura diretta dei casi di test con i metodi (o di classi di test per le classi sotto test), perché generalmente non ci sarà una mappatura uno-a-uno dei requisiti a metodi / classi.
API di prova
I test unitari sono necessariamente accoppiati all'interfaccia pubblica dell'unità che stanno testando. Va bene, perché se il tuo sistema è collegato in modo approssimativo, solo i test relativi a quell'unità sono influenzati dai cambiamenti.
Dal contesto della citazione che hai fornito, deduco che la preoccupazione di Martin è l'accoppiamento di test di integrazione / accettazione con la struttura interna del sistema, o con dettagli come la GUI (come discusso nella pagina precedente) . Se ciò accade, una modifica a una classe potrebbe non richiedere più solo una modifica a pochi test di unità, ma a un numero potenzialmente elevato di test di livello superiore.
Per evitare questo, questi test dovrebbero accedere al sistema attraverso un'API stabile. Gli interlocutori sono un buon candidato. Ma a volte gli interattori potrebbero non essere sufficienti per le vostre esigenze di test: potrebbero non essere abbastanza stabili, richiedere l'esecuzione di una logica difficile o costosa o vincolarvi per altri motivi (ad es. Sicurezza).
Per questi casi, Martin propone di fornire un'API estesa utilizzata solo dai test. Questa API protegge quindi i test dagli interni, allo stesso modo in cui gli utenti interagiscono con l'interfaccia utente.