Esiste un vantaggio per il codice di test unitario il cui unico scopo è generare codice non leggibile da un utente in un'altra lingua?

5

Una parte significativa dell'applicazione su cui lavoro ogni giorno è costituita da Javascript che emette molte (come potrebbe essere) le formule del foglio di calcolo di Excel. Sì, Excel è a malapena un linguaggio completo di Turing, ma le formule sono più che complesse da qualificarsi come "codice". Non sono pensati per essere leggibili o modificabili dall'uomo. Gli utenti non vedono mai queste formule, solo i valori valutati da quelle formule.

Il problema principale con il nostro codebase in questo momento è la mancanza di test automatici, e finora ho concentrato i miei sforzi sui test di integrazione che eseguono sia il Javascript che le formule, quindi asserisco sui valori finali. Dopotutto, non ci importa quali formule siano state usate per creare quei valori, quindi non vedo davvero il punto in un test unitario che asserisce sulle formule prodotte da ciascun pezzo di Javascript. Mi aspetto anche che tali test unitari siano estremamente fragili, poiché la maggior parte delle nostre modifiche al codice Javascript hanno lo scopo di modificare le formule in qualche modo (anche se in un modo che non dovrebbe influire sulla maggior parte di i valori finali).

Si noti che il codice che valuta le formule è di proprietà di un diverso team e su di esso hanno un sacco di test unitari. Sono interessato ai test per il nostro codice, la parte che genera le formule.

Si noti inoltre che la velocità è un non-problema; i test di integrazione che ho scritto finora sono così veloci da sembrare più come test unitari.

Per i motivi sopra riportati sono convinto che migliorare la copertura dei test di integrazione sia la priorità più alta, almeno per ora, ma onestamente non riesco a vedere alcun vantaggio alle unità che testano questo codice, che sembra un segno che potrebbe mancare qualcosa di importante.

Quindi, c'è qualche scopo di avere test unitari e test di integrazione per questo particolare tipo di codice, in cui l'unico obiettivo è generare "codice" in qualche altra lingua, e a nessuno importa quale "codice intermedio" sia usato per raggiungere il risultato finale?

    
posta Ixrec 09.09.2015 - 22:26
fonte

2 risposte

3

In genere sostengo che ci sono usi. Tali usi potrebbero non essere applicabili a te in questo specifico scenario, ma potrebbero.

  • Cosa succede quando i test di integrazione falliscono?

Ora puoi scavare nel codice per restringere quale fosse la vera causa alla radice. Se avessi dei test unitari solo per la generazione della formula, fornirebbe prove chiare (senza alcun lavoro o supposizione da parte tua) se fosse la generazione della formula che si è rotta o i bit di esecuzione.

  • Che cosa succede quando passi a un nuovo framework di esecuzione?

Presumibilmente, la tua azienda dovrà comunque calcolare tutti questi valori. Se il tuo quadro di esecuzione cambia, dovrai modificare la sintassi di output. Idealmente hai qualche forma agnostica di implementazione per le tue formule. I test unitari aiutano a capire che parte del codice è corretta, così quando cambi la sintassi del target puoi avere la certezza che non cambierai anche la semantica.

  • Cosa succede quando il framework di esecuzione viene aggiornato? Rompe i tuoi test? Come sai che è ciò che ha rotto i test?

Il disaccoppiamento consente di ridurre l'impatto delle modifiche, anche nei test.

  • Quanto tempo ci vuole?

Forse non è un problema per te, ma i test di integrazione tendono ad essere più complessi. Ciò significa che è più lento correre, più lento da scrivere, più lento da mantenere. Se i test unitari sono efficaci al 95% rispetto ai test di integrazione, ma impiegano la metà del tempo necessario, potrebbero essere l'opzione migliore (almeno in parte).

Anche in questo caso potrebbero non essere applicabili in questa situazione, ma sarebbero i miei argomenti predefiniti per il test dell'unità anche in un ambiente in cui i test di integrazione sembrano abbondantemente sufficienti.

    
risposta data 09.09.2015 - 23:18
fonte
7

Una forma più breve della tua domanda sarebbe "i test unitari hanno senso per un compilatore". Credo che la risposta a questa domanda sia un strong sì. Devi sapere che le parti più piccole della tua pipeline di trasformazione fanno quello che dovrebbero. Devi sapere che sono combinati correttamente e così via.

Direi che i test unitari, i test di integrazione e i test end-to-end hanno tutti un senso.

    
risposta data 10.09.2015 - 11:51
fonte

Leggi altre domande sui tag