Perché la pratica di scrivere unit test in una lingua diversa non è così popolare?

Question

Perché la pratica di scrivere unit test in una lingua diversa non è così popolare?

#1 da (6 voti)

4

Quando Microsoft ha rilasciato Visual Studio 2008, c'era una cosa di cui stavano parlando molto durante le conferenze e nelle loro esercitazioni online: l'idea di scrivere il codice reale in una lingua e l'unità test in una lingua diversa. Ad esempio, i test unitari per il codice C # possono essere scritti in Visual Basic.

Sei anni dopo, non conosco nessun progetto open source che usi questa pratica e nessun progetto proprietario che ho visto utilizzi. L'argomento non è più discusso nelle conferenze, nei blog o nelle esercitazioni di Microsoft.

Il vantaggio di questa pratica è che fare lo stesso tipo di errore in due lingue diverse è più difficile. Ad esempio, se non lo so in C #, 10/3 equivale a 3 e aspettiamo che sia 3.333... , un test unitario scritto in Python o JavaScript fallirà e mi porterà alla scoperta nella divisione integer.

.NET Framework, in particolare, rende possibile l'utilizzo di qualsiasi linguaggio abilitato a .NET per testarne un altro. Mentre testare il codice C # con i test di Visual Basic non sembra particolarmente interessante, data la somiglianza di entrambi i linguaggi, immagino che, ad esempio, testare il codice F # con test unitari scritti in C # possa essere utile per le persone che non hanno familiarità con programmazione funzionale.

Personalmente, non ho esperienza di scrittura dei test unitari in una lingua diversa. Pertanto, non so se ci sono dei veri inconvenienti in questa tecnica. Scrivo spesso test di sistema e di accettazione in una lingua diversa (ad esempio in Python per un'app Web Node.js, perché le richieste di Python la libreria è così grande), ma questo non conta, dal momento che quei test sono veramente indipendenti dal linguaggio: eseguono solo test black box tramite HTTP: posso riscrivere un'app da Node.js a ASP.NET MVC, e i test non noteranno nemmeno il cambiamento.

Quindi quali potrebbero essere gli svantaggi e perché questa pratica non è così popolare?

language-agnostic unit-testing language-choice interoperability

posta Arseni Mourzenko 23.02.2015 - 20:56

fonte

1 risposta

Leggi altre domande sui tag language-agnostic unit-testing language-choice interoperability

Const significa thread-safe? [chiuso] Eccezioni in ANSI C

score 6 · Accepted Answer

I test unitari sono test white-box e solitamente scritti dagli sviluppatori della cosa sottoposta a test. Il primo significa che è necessaria un'interazione di prima classe con le API e oggetti e valori della lingua in cui è scritto il prodotto reale, che esclude quasi tutte le combinazioni di lingue. In effetti, penso che il CLR sia l'unico agglomerato di lingue che ognuno può chiamare perfettamente l'uno nell'altro. E come dici tu, la maggior parte dei linguaggi CLR è così simile che nessuno dei vantaggi suggeriti si applica.

Questo lascia praticamente solo la combinazione di F # e C # / VB.NET. Posso immaginare diverse ragioni per cui non è decollato:

F # non ha una grande comunità. Al contrario, la maggior parte degli sviluppatori di C # non conosce abbastanza F # per poterlo considerare.
Le persone che conoscono F # sono impegnate a scrivere sia i test unitari che il codice effettivo in F #, o in una squadra in cui non possono usare F # perché nessuno lo sa (bene). Come accennato in precedenza, i test unitari di solito non sono scritti da una squadra separata, quindi le persone che scrivono i test dell'unità C # per il codice F # probabilmente devono ancora sapere F #. Inoltre l'intera cosa della white-box: se non sai nulla della programmazione funzionale, anche le strutture dati e le API esposte da F # (idiomatica) saranno innaturali per te una volta che approfondirai le librerie molto più semplici della forma "messo in un URL qui, ricevi IEnumerable<UrlParameter> .
Non c'è alcun beneficio (o la gente non crede al beneficio), ma molto probabilmente un po 'di vera frizione derivante dal cambiare linguaggio costantemente.