Ci dovrebbero essere dei test unitari per espressioni regolari complesse?

A parte il dogmatismo, la vera questione è se fornisce valore alle espressioni regolari complesse del test unitario. Sembra abbastanza chiaro che fornisce valore (indipendentemente dal fatto che la regex faccia parte di un'interfaccia pubblica) se l'espressione regolare è abbastanza complessa, in quanto consente di trovare e riprodurre bug e prevenire regressioni.

Regex può essere un potente strumento, ma non è uno strumento di cui ti puoi fidare, se lavori ancora solo con piccole modifiche alle espressioni ree complesse.

Quindi crea molti test che documentano i casi che dovrebbe coprire. E crea molti test che documentano i casi in cui dovrebbe fallire, se è usato per la convalida.

Ogni volta che devi modificare le espressioni regolari, aggiungi i nuovi casi come test, modifica la tua espressione regolare e sperare per il meglio.

Se fossi in un'organizzazione che in generale non usava i test unitari, scriverei comunque un programma di test che testerebbe qualsiasi regex che useremmo. Lo farei anche nel mio tempo libero, se necessario, i miei capelli non hanno bisogno di perdere più colore.

Le espressioni regolari sono codice insieme al resto della tua applicazione. Dovresti testare che il codice nel complesso faccia quello che ti aspetti che faccia. Questo ha diversi scopi:

• Test sono documentazione eseguibile. Dimostra chiaramente quello che ti serve il codice da fare. Se è testato, è importante.
• I futuri manutentori possono essere certi che se lo modificano, i test garantiranno che il comportamento non sia cambiato.

Poiché c'è un ostacolo in più da superare con il codice in una lingua diversa incorporata con il resto, molto probabilmente dovresti prestare questa attenzione in più a beneficio della manutenzione.

In breve, dovresti testare la tua domanda, periodo. Sia che tu testi la tua regex con test automatici che la eseguono in modo isolato, come parte di una scatola nera più grande o se la maneggi con la mano è secondaria al punto che devi assicurarti che funzioni.

Il vantaggio principale dei test unitari è che risparmiano tempo. Ti permettono di testare la cosa tutte le volte che vuoi ora o in qualsiasi momento nel futuro. Se c'è qualche ragione per credere che la tua espressione regolare sarà in qualsiasi momento rifattorizzata, ottimizzata, ottenere più vincoli, ecc, allora sì, probabilmente vorrai qualche test di regressione per questo, o quando lo cambierai, dovrai andare attraverso un'ora di riflessione attraverso tutti i casi limite in modo da non romperlo. Quello, o impari a vivere con la paura del tuo codice e semplicemente non lo cambi mai.

On the other hand: they themselves are seldom part of the interface of some unit. It might be better to only test the interface and do that in a way that implicitly tests the regexes.

Penso che con questo tu abbia risposto da solo. I regex in un'unità sono molto probabilmente un dettaglio di implementazione.

Ciò che vale per testare il tuo SQL probabilmente vale anche per le espressioni regolari. Quando si modifica una parte di SQL, è probabile che venga eseguita manualmente tramite un client SQL per vedere se restituisce ciò che si aspetta. Lo stesso vale per quando cambio una regex, uso qualche strumento di regex con qualche esempio di input per vedere se fa quello che mi aspetto.

Ciò che trovo utile è un commento vicino alla regex con un campione di testo che dovrebbe corrispondere.

Se devi chiedere, la risposta è sì.

Supponiamo che alcuni FNG arrivino e pensa di poter "migliorare" la tua espressione regolare. Ora, è un FNG, quindi automaticamente un idiota. Esattamente il tipo di persona che non dovrebbe toccare il tuo prezioso codice in nessuna circostanza, mai! Ma forse è imparentato con PHB o qualcosa del genere, quindi non c'è niente che puoi fare.

Tranne che sai che il PHB ti trascinerà a calci e urlando a questo progetto per "forse dare al ragazzo alcune indicazioni su come hai fatto questo casino" quando tutto va male. Quindi scrivi tutti i casi in cui hai attentamente considerato quando costruisci il tuo bellissimo capolavoro di expressiondom.

E dal momento che li hai scritti tutti giù, sei a due terzi del modo di avere una serie di casi di test, dal momento che - diciamocelo - i casi di test di regex sono morti facilmente eseguibili una volta che hai ottenuto framework costruito.

Quindi ora hai una serie di condizioni limite, alternative e risultati attesi. E improvvisamente i casi di test sono la documentazione proprio come promesso in tutti quei post del blog di Agile. Basta segnalare al FNG che se il suo "miglioramento" non supera i casi di test esistenti, non è un gran miglioramento, vero? E dove sono i suoi nuovi casi di test che dimostrano qualche problema con il codice originale, che dal momento che funziona non ha bisogno di essere modificato, mai !!!