Confini di test unitari tra il mio codice e una libreria o sottocomponente

Contesto: sono nuovo nel test in generale e lo sto studiando nel contesto di JavaScript, in particolare React.js, sviluppo front-end (in realtà anche nuovo). Per la domanda, ho questi 2 casi simili:

Caso 1: il mio codice e una libreria

Uso la libreria dell'interfaccia utente e, a parte il suo design decente, voglio sfruttare le sue utilità di convalida dei moduli. Voglio testare questa convalida, ma non sono sicuro di come farlo.

• Opzione 1: prova solo per i comportamenti che mi aspetto

  Sarebbe testare se il mio campo (che è un sottomodulo della libreria stessa) riceve le classi specifiche della libreria per i campi con errori come previsto, e se questi errori impediscono di chiamare il gestore di invio ho passato al modulo (anche sotto-modulo della biblioteca).

  • Problema A con l'opzione 1

    Molto probabilmente sto duplicando test che sono già coperti dalla libreria stessa. (Ad esempio, sto verificando se il campo riceve le classi di errore quando l'input non è valido quando la libreria stessa ha testato se lo fa, data la configurazione corretta.)

  • Problema B con l'opzione 1

    Lega leggermente il codice di test alla libreria, cioè devo usare classi e markup specifici della libreria per valutare il mio codice.

    Ok, questa è in realtà una domanda a parte, è una cosa brutta per un test? Questo rende il test fragile, o è quello che chiamano "contratto" che è effettivamente necessario per i test unitari?

• Opzione 2: verifica quale sottomodulo viene utilizzato e quale configurazione è passata

  • Problema A con l'opzione 2

    Questo è molto più fragile, penso, È quasi come ripetere l'implementazione (cioè ripetere il sottomodulo di tipo usato e la configurazione passata ad esso.)

  • Problema B con l'opzione 2

    Come il problema A di Opzione 1 - test di accoppiamento all'API della libreria, in particolare la sua API di configurazione. (Di nuovo, non sono sicuro che questo sia solo un test fragile, o un contratto scritto)

Caso 2: il mio codice e il suo sottocomponente

Ho il mio buono 'ol to do app . Il suo componente to do list ha il metodo addTodo() e passa al suo componente secondario to do field . Voglio testare la sua funzionalità per aggiungere l'articolo, ma non sono sicuro su come farlo.

• Opzione 1: Di nuovo, prova solo per i comportamenti che mi aspetto

  Test 'to do app' that if input and submit with sub-component 'to do field', another 'to do item' is added. (This is implemented by passing 'addTodo()' method from 'to do app' to 'to do field' as onSubmit handler)
  

  • Problema A con l'opzione 1

    Se lo farò, c'è ancora un punto in unità che testa il to do field da solo? Se ho già testato unitamente to do field che chiama qualsiasi gestore onSubmit al momento dell'invio, questo% test di casi di prova di to do app ripeterà indirettamente il caso di test to do field ??

• Opzione 2: verifica se viene utilizzato il sottocomponente corretto e quale configurazione viene passata (simile all'opzione 2 del caso 1)

  Le sue specifiche sarebbero le seguenti:

  • Test unitario to do app per affermare ...
    • il metodo to do app di addTodo() aggiunge un elemento todo correttamente
    • che to do app rende to do field sotto-componente
    • e che to do app passa addTodo() a come gestore onSubmit a to do field
  • quindi anche unit test to do field per affermare che ...
    • che to do field chiama onSubmit, che viene ricevuto dal componente principale, durante l'invio

La domanda

Quale di queste opzioni è migliore, soprattutto se preferisco BDD rispetto a TDD? Inoltre, per favore correggimi se hai notato che ho frainteso qualcosa. Grazie.