Esistono framework di test unitari indipendenti dalla lingua? [chiuso]

11

Sono sempre stato scettico sulla riscrittura del codice di lavoro - il porting code non fa eccezione. Tuttavia, con l'avvento del TDD e dei test automatizzati è molto più ragionevole riscrivere e refactificare il codice.

Qualcuno sa se esiste uno strumento TDD che può essere utilizzato per il porting del vecchio codice? Idealmente potresti fare quanto segue:

Scrivi test di unità indipendenti dalla lingua per il vecchio codice che passa (o fallisci se trovi dei bug!).
Esegui unit test sull'altra tua base di codice che falliscono.
Scrivi il codice nella tua nuova lingua che supera i test senza guardare il vecchio codice.

L'alternativa sarebbe quella di dividere il passaggio 1 in "Scrivere unit test nella lingua 1" e "Port unit test in language 2", il che aumenta significativamente lo sforzo richiesto ed è difficile giustificare se la vecchia base di codice non smetterà di essere mantenuta dopo la porta (ovvero, non si ottiene il vantaggio di una continua integrazione su questa base di codice).

EDIT: Vale la pena notare questa domanda su StackOverflow.

unit-testing language-agnostic porting

— Bringer128
fonte

Fornire un protocollo di comando di testo puro, quindi utilizzare expectper implementare i test.

— SK-logic,

@ SK-logic di cui non avevo sentito parlare expect. Se hai un sistema legacy in stile Unix che comunica con le pipe usando stdin e stdout, allora quello strumento può essere sicuramente usato. In effetti, sarebbe abbastanza facile testare anche con qualsiasi linguaggio di scripting.

— Bringer

perché eredità? Puoi avere anche un sistema moderno in stile unix. Comunque, non esiste mai una giustificazione valida per non fornire un'interfaccia di scripting a nessuna funzionalità.

— SK-logic,

@ SK-logic Ci scusiamo per non essere chiari. Ho detto "eredità" perché il porting viene generalmente eseguito da legacy language xa fancy new language y. Non stavo tentando di insinuare nulla su Unix!

— Bringer

@ Bringer123, a proposito, il mio piccolo trucco per fare questo tipo di integrazione simile a unix senza alcun supporto Unix decente (ad esempio, senza pipe appropriate) è incorporare un linguaggio di scripting e fornire un accesso al suo REPL tramite porta TCP (con REPL in esecuzione in un thread separato). È sia un potente strumento di debug sia un motore di automazione dei test. E questo approccio funziona letteralmente con tutto (un linguaggio di scripting incorporato può essere davvero minuscolo, può anche essere un Forth in uno scenario di risorse limitate).

— SK-logic,

6

Non credo sia possibile scrivere unit test in un'altra lingua.

Tuttavia, ciò che puoi fare è scrivere test di integrazione / accettazione / interfaccia utente / whaterver_you_name_it che sarebbero di altissimo livello e non sarebbero legati alla lingua con cui il tuo software è scritto.

Se la tua applicazione è un servizio web, puoi testarla con qualsiasi lingua tu voglia, purché supporti il tuo protocollo. Se l'applicazione viene eseguita in un browser, è possibile utilizzare il selenio (questo è il primo che mi è venuto in mente, ma ce ne sono altri. Ecc. Potrebbero esserci alcuni casi in cui non funzionerebbe, immagino (forse roba hardware), tutto dipende sul tipo di applicazione su cui stai lavorando.

Ovviamente, non avrai la stessa copertura che avresti con i test a livello di unità (a meno che non passi molto tempo), ma almeno, avresti un cablaggio di prova.

— David
fonte

+1 per i test automatizzati di alto livello. Vale sicuramente la pena di produrli.

— Bringer

1

"Non credo sia possibile scrivere unit test in un'altra lingua". : esempio contatore: in .NET, è possibile scrivere unit test di C # in Visual Basic (o in qualsiasi altro linguaggio abilitato per .NET). Alcuni anni fa, questo è stato persino promosso da Microsoft come best practice, poiché riduce il rischio di commettere in entrambi i codici e verifica lo stesso errore correlato al linguaggio (e in particolare il relativo fraintendimento del programmatore). D'accordo, non si scriveranno unit test in Fortran per testare il codice PHP.

— Arseni Mourzenko,

2

Penso che ciò che si avvicina di più alla tua idea siano i framework di unit test su ecosistemi basati su macchine virtuali come Java VM. Almeno Scala (e credo anche a Groovy - non sono del tutto sicuro di Clojure) è quasi perfettamente interoperabile con Java. Cioè, il codice Scala può essere testato con JUnit e il codice Java può essere testato con ScalaTest. In questo modo è possibile (gradualmente o contemporaneamente) riscrivere il codice Java in Scala e continuare a utilizzare gli stessi vecchi test delle unità Java per verificarne la correttezza. (O viceversa - anche se non riesco a immaginare un motivo valido per migrare da Scala a Java.)

Probabilmente lo stesso vale per i linguaggi sulla CLI .NET, ad esempio C #, F #, ASP.NET et al.

Al di fuori di una VM / CLR, tuttavia, è più difficile. In teoria, si potrebbero compilare unit test e / o codice testati in un altro linguaggio come C (com'era ed è comune con nuovi linguaggi come i primi C ++ ecc.), Ma non ho sentito di nessuno che lo provi specificamente con test unitari.

— Péter Török
fonte

1

Immagino che questo mostri il problema con la mia domanda. Se possono interagire facilmente, perché port? E se non ci riescono, la barriera linguistica rende impossibile eseguire test unitari in più lingue.

— Bringer

@ Bringer128, i fautori della nuova generazione di linguaggi JVM sostengono che problemi specifici possono essere risolti più velocemente, con un codice significativamente inferiore e più pulito rispetto a Java. La mia esperienza limitata con Scala lo conferma finora.

— Péter Török,

Groovy interagisce anche con Java.

— user281377,

1

Tale framework non esiste, perché deve essere scritto nella lingua del codice utilizzato.

Ad esempio, un framework per testare il codice c ++ deve essere scritto in c o c ++. L'uso del framework scritto in c ++ potrebbe, ma non testerà il codice ac se utilizza le funzionalità c ++.

— BЈовић
fonte

1

Le metodologie variano, ma nel mio caso gran parte dei miei test TDD tende allo stile del "test di integrazione", a differenza del "test unitario". Cioè, la maggior parte dei miei testano l'intero programma con domande quasi reali, verificando le risposte appropriate.

In alcuni casi, quando ho scritto programmi guidati dalla rete (principalmente protocolli specifici dell'applicazione), non avevo a portata di mano un framework di test completo che fosse facile per il lavoro, quindi ho svolto la maggior parte dei test "attraverso la rete", in in breve, ho scritto un client molto semplice in un'altra lingua con un framework di test comune e semplice e la maggior parte dei test ha verificato le risposte del server.

Tuttavia, anche in quei casi, ho iniettato alcuni test eseguiti a mano nell'applicazione reale per testare alcune parti non di rete.

— Javier
fonte

0

Il framework di test agnostico del linguaggio è un framework di test generico adatto al test di accettazione (punto di vista) e i test in quel framework sono gestiti dal QA, ad es. Robotframework

— rrsguru
fonte

2

questo non sembra offrire nulla di sostanziale rispetto ai punti formulati e spiegati nelle precedenti 4 risposte

— moscerino del