La distinzione non riguarda l'orientato agli oggetti o no, ma piuttosto il test delle singole funzioni ("white box testing") rispetto ai programmi completi ("black box testing"). E non si tratta di casi separati come un continuum in cui varie tecniche sono mescolate e abbinate.

Gli strumenti non sono monolitici. Un framework di test consiste di quattro cose:

• Il test runner
• Il reporter del risultato
• La raccolta di asserzioni
• (opzionalmente) Mock framework di oggetti

Questi componenti sono per lo più ortogonali e le loro implementazioni indipendenti possono essere combinati, sia i diversi tipi di componenti sia le molteplici implementazioni di ciascuno di essi.

Il test runner

Il componente che trova tutti i casi di test e li esegue. È possibile combinare più test runner semplicemente chiamando un corridore di test come test case da un altro corridore. Può essere semplice come un ciclo su una directory di script e questo è esattamente quello che spesso si utilizza come runner di primo livello quando si combinano test scritti in framework diversi.

Puoi trovare alcuni test runner universali in CTest o shUnit . Entrambi forniscono anche metodi per confrontare gli output nei file.

Il perl Test :: Harness può anche essere considerato corridore generale come esegue script nella directory. E perl è adatto anche per testare programmi esterni.

Il giornalista

Ogni framework di test unitario produce un elenco di test falliti. Se combini più framework, puoi semplicemente raccogliere tutti i singoli report o utilizzare qualcosa come subunità o Test::Harness "tocca" per fornire progressi e riepilogo uniformi.

Le asserzioni

Questo è il modo in cui test il codice testato produce risultati attesi ed è legato alla modalità di interfacciamento del codice.

• Per le librerie in vari linguaggi di programmazione ci sono le asserzioni fornite dal rispettivo xUnit.
• Per gli strumenti da riga di comando ci sono vari comparatori di file. CTest e shUnit ne hanno alcuni, ma sono per lo più facili da usare in homebrew se necessario.
• Per gli strumenti da riga di comando interattivi c'è expect (o è Perl variante ).
• Per le applicazioni della GUI c'è LDTP (progetto di test del desktop di Linux, ma ora anche le versioni di windows e macos)
• Sono sicuro di aver visto qualcosa per le applicazioni web (significa nel browser, si testano i servizi attraverso la loro libreria client), ma non ricordo alcun nome. Ne troverai sicuramente alcuni con Google.

Strumento di simulazione

Si tratta di costruire l'ambiente di test senza impostare tutte le dipendenze reali. Per esempio. configurare un livello di accesso al database che restituisca un insieme specifico di risposte senza impostare il database effettivo e tali.

Non è possibile automatizzare tanto quanto è necessario fornire i dati che dovrebbe restituire. Spesso non è quello che vuoi comunque. Cioè è necessario testare l'applicazione con dati campione nel database effettivo o in un'altra fonte di dati e il test dei moduli a grana fine aggiuntivo spesso richiede molto lavoro con rendimenti decrescenti.

Non penso che molto possa essere generalizzato per questo. Per la maggior parte degli xUnits c'è qualcosa che genererà implementazioni fittizie per le interfacce, ma questo è tutto. Di quanto devi semplicemente considerare cosa richiede il componente da testare e qual è il modo più semplice per fornirlo localmente. Per qualcosa che comunica con alcuni servizi Web è possibile eseguire localmente un server http leggero. Per lo strumento di database che utilizza ODBC (o DBI o qualsiasi altra API universale), puoi testarlo su sqlite anche se normalmente utilizza un server grande, ecc. Per strumenti che leggono solo i file, ovviamente copi solo in un set di dati di prova adatto.

Non sono del tutto sicuro di quale tipo di strumenti stai parlando o di cosa li rende difficili da testare.

Ma potrebbe valere la pena dare un'occhiata a ApprovalTests ? Si tratta di un framework in più lingue (Java, C #, VB.Net, PHP, Ruby) che si trova sotto qualsiasi unità di test runner. Prende l'approccio di: invece di scrivere e testare e specificare il risultato atteso, scrivi il test, non specifica un risultato, esegui il test e poi ti mostra il risultato. Lo approvi. Da quel momento in poi, ogni volta che esegui il test, passerà se il risultato è invariato rispetto a quando lo hai approvato, e fallirà (presentandoti con una diff) se è cambiato.

Questo è ottimo per testare codice che restituisce più di semplici risultati scalari (raccolte, documenti XML, ecc.) E poiché viene eseguito in uno qualsiasi dei principali framework di test delle unità, non si perde nessuno dei propri strumenti per l'automazione , ecc.