Diciamo che si fa un'applicazione che tenta di traslitterare materiale dall'alfabeto A all'alfabeto B, il più vicino possibile.In caso di esito positivo di tutti i test unitari?
Poiché il linguaggio B è molto complesso, questo non sempre ha esito positivo. Ma ottieni una traslitterazione approssimativa.
In che modo si dovrebbero creare test unitari in questo caso, considerando che ci si aspetta che il 20-30% non funzioni?
Deve sempre essere l'obiettivo che il test dell'unità ha avuto esito positivo. Nel modo in cui lo si utilizza, non è possibile distinguere tra errori gravi nel software e errori nelle traduzioni che si prevedono.
vorrei suggerire di separare entrambi:
Un test dell'unità che è previsto non riuscire non è un test unitario. È necessario modificare la definizione del successo utilizzando una funzione di valutazione che funge da filtro e decide se è "abbastanza vicino" e determina il pass/fail. Mentre il tuo traduttore migliora, puoi alzare la barra nel filtro.
Il test dell'unità deve essere deterministico. Il test fallito dovrebbe indicare un errore del software, non qualcosa che "funziona come previsto". Per il tuo caso, prepara i dati in modo da essere sicuro dei risultati e testarli, se la conversione ha esito positivo o negativo (il test per il fallimento è sempre un'opzione, dato che si aspetta un errore - importante è che tu abbia sempre il controllo di quando il test supera/fallisce).
Una tecnica che ho imparato in questa situazione è di testare solo le parti del codice che sono funzionali (o deterministiche). Certo, la parte difficile è separare le parti deterministiche da quelle non deterministiche. Il modo stenografico per dire questo è "ridurre [o refactoring] in funzionale", il che significa separare le parti del codice che sono deterministiche e quindi testare quelle parti.
Per un po 'basati su scenari di contesto, leggere questo post su blog l'applicazione di questa tecnica quando ottiene i test in tutto il codice legacy (e utilizzando la libreria unit testing open source chiamato ApprovalTests).
Un'altra tecnica che può essere interessante qui è il test "basato sulla teoria". Per ulteriori informazioni, controlla questo post blog.
L'unico motivo per cui un test dell'unità potrebbe non riuscire è se il tempo è coinvolto (soprattutto nel caso di test elettronici). Tuttavia, anche se tali casi, dovrebbe essere l'obiettivo di rimuovere il problema di temporizzazione dal test unitario, ad es. estendendo/cambiando il timeout o altri problemi di temporizzazione se possibile. Quando non è possibile, dovrebbe essere ben documentato.
Un altro modo per rimuovere i problemi di temporizzazione e rendere deterministici i test è scrivere gli stub per tutte le interfacce esterne, con qualche metodo di iniezione, cioè essere in grado di impostare valori che restituiranno i metodi di interfaccia esterna. Impostando un test unitario in questo modo, puoi testare letteralmente tutto anche ogni condizione di errore.
(storia: ho lavorato presso una società dove diversi test di unità sarebbero falliscono occasionaly Solo poche persone erano in grado di analizzare se quelle erano gravi errori o un problema di temporizzazione Ciò consentirà di risparmiare un sacco di tempo per fare le buone prove di unità a.. il primo posto).
+1 per separare * unit * test che convalidano la correttezza del programma dai test di * accettazione * che convalidano che il programma soddisfa i requisiti specificati. –