Che cos'è il test dell'unità scatola nera?

Il tuo professore ha ragione: i test unitari possono essere sia black-box che white-box. La differenza è meno su ciò che sa il tester, ma più su come si generano i casi di test.

Con il test della scatola nera, si guardano solo l'interfaccia e (se esiste) le specifiche per un componente. Quando una funzione ha una firma int foo(int a, int b) , posso immediatamente generare alcuni casi di test semplicemente testando interi interessanti: zero, uno, meno uno, numeri a più cifre, INT_MAX, INT_MAX - 1 e così via. I test della scatola nera sono grandi perché sono indipendenti dall'implementazione. Ma potrebbero anche mancare casi importanti.

Con un test white-box, guardo all'implementazione, cioè il codice sorgente e genera casi di test da quello. Ad esempio, potrei voler ottenere una copertura del percorso del 100% per una funzione. Quindi scelgo i valori di input in modo che vengano presi tutti i percorsi. I test white-box sono grandi perché possono esercitare in modo esaustivo un pezzo di codice, con molta più sicurezza di un test black-box. Ma potrebbero solo testare i dettagli dell'implementazione, non un comportamento realmente importante. In alcuni casi, sono chiaramente una perdita di tempo.

Poiché un test white-box deriva dall'implementazione, può essere scritto solo successivamente. Un test black-box deriva dalla progettazione / interfaccia / specifica e può quindi essere scritto prima o dopo l'implementazione. TDD non è nè chiaramente scatola nera o scatola bianca. Dal momento che tutti i comportamenti vengono espressi per la prima volta da un test e quindi viene implementato il codice minimo per tale comportamento, il TDD risulta in casi di test simili a un test white box. Ma quando guardiamo al flusso di informazioni, i test TDD non derivano dal codice sorgente, ma da requisiti esterni. Pertanto, TDD è più simile a una scatola nera.

Se stai intraprendendo lo sviluppo basato sui test, allora in teoria tutti i tuoi test unitari dovrebbero essere black-box. Questo è il tuo "approccio test-first". Scrivi il contratto (interfaccia), scrivi i test per quel contratto e poi il contratto è soddisfatto dall'implementazione. Pertanto, il test non sa nulla e non dovrebbe sapere nulla dell'implementazione.

Dopotutto, quando scrivi un test, cosa stai testando? Metodi / funzioni pubbliche.

Se dovessi scrivere l'interfaccia per una classe, e poi scrivere i test, e poi sarai investito da un autobus, il ragazzo che scrive la classe mentre sei in ospedale dovrebbe essere in grado di farlo dalla tua interfaccia , destra? Non dovrebbe doverlo buttare via e scrivere la sua interfaccia e test.

Dove questo va a pezzi è quando devi prendere in giro qualcosa di cui dipenda l'implementazione, ma se ti trovi nella situazione in cui stai prendendo in giro qualcosa che non viene mai esposto pubblicamente, allora hai fatto un errore, e devi guardare a Dipendenza iniezione et al . Quindi direi che il test delle unità white-box, non il nero, dovrebbe essere l'eccezione.

Considera "Test sul water - Comportamento del test non attuare l'implementazione" , in cui l'implementazione di una classe viene modificata ma i test dovrebbero essere ancora validi.

Tuttavia, se hai bisogno di assicurarti che la copertura del tuo codice sia attiva (cioè assicurati che tutti i percorsi condizionali siano testati all'interno dell'implementazione), allora dovresti assolutamente fare un test unitario in white box, perché l'unico modo in cui puoi sapere quali sono i tuoi percorsi osservando i percorsi dell'implementazione.

Direi che tutti i test unitari ben scritti sono intrinsecamente "scatola nera". Certo, potrei avere un'implementazione in mente quando scrivo il test, ma l'implementazione potrebbe cambiare quando eseguo il refactoring. Quindi il test dovrebbe utilizzare solo API pubbliche durante il test per testare la funzionalità, non l'implementazione. A lui non interessano i dettagli di implementazione, quindi il test della scatola nera.

Se scrivo test che accedono agli aspetti interni o privati dell'unità in prova, sto testando i dettagli dell'implementazione: I'm white box testing. Ma sto anche scrivendo test fragili che possono essere facilmente interrotti quando l'implementazione viene cambiata. Quindi tali test di riquadri bianchi sono una cattiva idea e dovrebbero essere evitati.

Conclusione: se esegui un test della scatola bianca con i test unitari, hai dei test mal costruiti. Solo test di back-box con quei test unitari. Il tuo professore ha ragione: può essere sia. Ma solo se fatto male.