Dovrebbero esserci test unitari per espressioni regolari complesse?

Devo scrivere unit test per espressioni regolari complesse nella mia domanda?

• Da un lato: sono facili da testare perché il formato di input e output è spesso semplice e ben definito, e spesso possono diventare così complessi, quindi i test di questi sono specificamente preziosi.
• D'altra parte: essi stessi fanno raramente parte dell'interfaccia di alcune unità. Potrebbe essere meglio testare l'interfaccia e farlo in modo da testare implicitamente le regex.

MODIFICARE:

Concordo con Doc Brown che nel suo commento osserva che questo è un caso speciale di test unitari dei componenti interni .

Ma poiché le regex dei componenti interni hanno alcune caratteristiche speciali:

1. Un regex a linea singola può essere davvero complesso senza essere un modulo separato.
2. Registra l'input della mappa in uscita senza effetti collaterali e quindi è davvero facile da testare separatamente.

Testando il dogmatismo a parte, la vera domanda è se fornisce valore per testare espressioni regolari complesse. Sembra abbastanza chiaro che fornisce valore (indipendentemente dal fatto che la regex sia parte di un'interfaccia pubblica) se la regex è abbastanza complessa, dal momento che ti permette di trovare e riprodurre bug e prevenire contro le regressioni.

Regex può essere uno strumento potente, ma non è uno strumento di cui ti puoi fidare per funzionare ancora se apporti modifiche anche minori a regex complesse.

Quindi crea un sacco di test che documentano i casi che dovrebbe coprire. E crea molti test che documentano i casi in cui dovrebbe fallire, se viene utilizzato per la convalida.

Ogni volta che devi cambiare le tue regex aggiungi i nuovi casi come test, modifica la tua regex e spera per il meglio.

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

Le espressioni regolari sono codice insieme al resto dell'applicazione. Dovresti testare che il codice in generale fa quello che ti aspetti che faccia. Questo ha diversi scopi:

• I test sono documentazione eseguibile. Dimostra chiaramente cosa devi fare per fare il codice. Se viene testato è importante.
• I futuri manutentori possono essere certi che se lo modificano, i test assicureranno che il comportamento rimanga invariato.

Dato che c'è un ulteriore ostacolo da superare avendo 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, punto. Sia che testiate il vostro regex con test automatici che lo eseguono in modo isolato, come parte di una scatola nera più grande o se vi armeggiate con esso manualmente, è secondario al punto che è necessario assicurarsi che funzioni.

Il vantaggio principale dei test unitari è che risparmiano tempo. Ti permettono di provare la cosa tutte le volte che vuoi ora o in qualsiasi momento in futuro. Se c'è qualche motivo per credere che il tuo regex sarà in ogni momento riformulato, ottimizzato, ottenere più vincoli ecc., Allora sì, probabilmente vorrai alcuni test di regressione per esso, o quando lo cambi, dovrai andare attraverso un'ora di riflessione su tutti i casi limite in modo da non averlo rotto. Quello o impari a convivere con la paura del tuo codice e semplicemente non lo cambi mai.

D'altra parte: essi stessi fanno raramente parte dell'interfaccia di alcune unità. Potrebbe essere meglio testare l'interfaccia e farlo in modo da testare implicitamente le regex.

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

Ciò che vale per il test del tuo SQL probabilmente vale anche per le regex. Quando cambi un pezzo di SQL, probabilmente lo esegui manualmente tramite alcuni client SQL per vedere se produce ciò che ti aspetti. Lo stesso vale per quando cambio un regex, uso alcuni strumenti regex con alcuni input di esempio per vedere se fa quello che mi aspetto.

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

Se devi chiedere, la risposta è sì.

Supponiamo che arrivi un po 'di FNG e pensi di poter "migliorare" la tua regex. Ora è un FNG, quindi automaticamente un idiota. Esattamente il tipo di persona che non dovrebbe mai toccare il tuo prezioso codice in nessun caso! Ma forse è legato al PHB o qualcosa del genere, quindi non c'è niente che tu possa fare.

Solo 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 che hai attentamente considerato quando costruisci il tuo bellissimo capolavoro di espressione.

E dal momento che li hai scritti tutti, sei i due terzi del modo di avere una serie di casi di test, poiché - ammettiamolo - i casi di test regex sono facili da eseguire una volta che hai costruito il framework.

Quindi ora hai una serie di condizioni limite, alternative e risultati attesi. E improvvisamente i casi di test sono la documentazione così come promesso in tutti quei post sul blog Agile. Fai notare all'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 prova proposti che dimostrano qualche problema con il codice originale, che dal momento che funziona non ha bisogno di essere modificato, mai !!!