No, non dovresti scrivere tali test.
Prima di tutto, questi test non possono essere eseguiti. Per rendere eseguibile questo test, è necessario creare un piccolo programma contenente l'errore e quindi eseguire il compilatore, verificando la presenza di errori nell'output. È perfettamente fattibile, ma non è veloce. L'unico scenario in cui ho visto tali test è lo script ./configure
nei progetti C o C ++ basati su Autotools, che compila piccoli programmi per verificare l'esistenza e la disponibilità di varie funzionalità e librerie del sistema host. Ma quelli non sono test unitari.
Ancora più importante, non dovresti scrivere tali test perché il test fornisce meno valore del sistema di tipo statico. I sistemi di tipo statico sono sistemi di prova automatizzati. Se dichiari un parametro come int
, allora sei garantito che il parametro mai riceverà un valore di qualsiasi altro tipo. Il tuo test dimostra semplicemente che la funzione rifiuterà un particolare valore, non che rifiuterà sempre tutti i valori illegali. I test sono esempi di correttezza, non di prove di correttezza. Una prova formale è una garanzia molto più strong di un test.
Ovviamente scrivere tali test se il sistema sotto test è un controllo di tipo. Quindi il sistema di tipi, non la funzione, dovrebbe rifiutare questo programma.
L'altro scenario in cui tali test sono desiderabili è il linguaggio digitato dinamicamente. Poiché nessun sistema di tipi garantisce che vengano forniti solo parametri appropriati, la codifica difensiva diventa più importante. I confini del sistema (ovvero l'API pubblica del programma) dovrebbero convalidare tutti i dati in entrata per verificare che siano conformi al contratto documentato. Poiché questo genera errori immediatamente al limite del sistema, gli errori derivanti da un utilizzo accidentale di queste funzioni diventano molto più facili da eseguire il debug. E proprio come qualsiasi altra caratteristica, questa convalida dovrebbe essere testata.