I test unitari non sono mai perfetti nell'acquisizione di funzionalità, in particolare in alcune parti di un'applicazione (come la GUI), quindi tutti hanno bisogno di alcuni test di black box. TDD ha qualcosa da dire sui test della scatola nera? Se non dice molto, potrebbe essere vero che mentre si scrivono i test unitari è il lavoro degli sviluppatori, i test funzionali della scatola nera cadono in un dominio diverso come quello di un analista aziendale o di un tester dedicato?
Il TDD si è evoluto per includere il test della scatola nera, il BDD lo utilizza in modo specifico come dispositivo (vedi ATDD ).
Tuttavia, non credo che questa risposta ti dica nel cui dominio si trova il test della scatola nera. Personalmente, penso che sia dovuto a tutti. Il BA sa cosa vuole l'azienda e gli sviluppatori e i tester comprendono casi limite che un BA non dovrebbe mai aver bisogno di capire, spesso entrambi con prospettive completamente diverse.
Ed è per questo che i Gherkin test runner sono diventati popolari, perché permettono BAs, Devs e I tester scrivono i casi di test nella stessa lingua l'uno dell'altro (sebbene gli sviluppatori debbano inserire del codice dietro al testo).
Does TDD have anything to say regarding black box testing?
Non proprio.
Devi prima scrivere i test. Pertanto, non esiste una "casella bianca" perché il codice non esiste ancora.
La distinzione tra riquadro nero e riquadro bianco non significa sostanzialmente nulla nel contesto TDD.
...could it be true that while writing unit tests is the developers job, functional black box tests fall into a different domain like that of a business analyst or a dedicated tester?
Sì. Certo.
TDD non significa "seguire rigidamente un percorso cerebrale".
Se vuoi fare test aggiuntivi della GUI, sarebbe un'idea ben accetta.
IMHO TDD è principalmente una tecnica whitebox e, penso che sia più una tecnica di implementazione che una tecnica di test. Viene applicato dallo sviluppatore che scrive il codice in piccole iterazioni "write test, write code, refactor", quindi da qualcuno che conosce esattamente le parti già implementate e le parti mancanti del "soggetto in prova".
Ogni volta che lo sviluppatore che applica TDD crea un test per una funzione, ha piena conoscenza dell'implementazione già esistente, della prossima caratteristica mancante, del prossimo caso limite mancante o dei percorsi del codice ancora scoperti. Ciò avrà indubbiamente una grande influenza in base alle prove che crea e quali no.
In effetti, c'è anche un elemento black box in TDD: ogni volta che crei una nuova funzione pubblica da testare, devi pensare alla firma della funzione o all'API dal punto di vista di un utente di tale funzione o API primo. E ogni volta che aggiungi un nuovo test per una funzionalità, il tuo "soggetto in prova" non supporta ancora, puoi farlo senza aver deciso come implementare la funzionalità in dettaglio. Ma IMHO che la parte black box è molto diversa da un vero "black box test", in cui un tester esterno che potrebbe non essere nemmeno uno sviluppatore non ha alcuna conoscenza circa l'implementazione di un programma.
Vedi anche: scatola nera o test della scatola bianca - che cosa fai prima?
Leggi altre domande sui tag testing unit-testing