Cosa significa "stub" nella programmazione?

Ad esempio, cosa significa in questa citazione?

L'integrazione con un'API esterna è quasi una garanzia in qualsiasi app web moderna. Per testare efficacemente tale integrazione, è necessario spegnerla . Un buon stub dovrebbe essere facile da creare e costantemente aggiornato con le risposte API attuali e attuali. In questo post, delineeremo una strategia di test utilizzando stub per un'API esterna.

Uno stub è un sostituto controllabile per una dipendenza esistente (o collaboratore) nel sistema. Utilizzando uno stub, è possibile testare il codice senza occuparsi direttamente della dipendenza.

Dipendenza esterna - Dipendenza esistente:
è un oggetto nel sistema con cui il codice sottoposto a test interagisce e sul quale non si ha alcun controllo. (Esempi comuni sono filesystem, thread, memoria, tempo e così via.)

Esempio nel codice seguente:

public void Analyze(string filename)
    {
        if(filename.Length<8)
        {
            try
            {
                errorService.LogError("long file entered named:" + filename);
            }
            catch (Exception e)
            {
                mailService.SendEMail("admin@hotmail.com", "ErrorOnWebService", "someerror");
            }
        }
    }

Vuoi testare il metodo mailService.SendEMail () , ma per farlo devi simulare un'eccezione nel tuo metodo di test, quindi devi solo creare un oggetto Fake Stub errorService per simulare il risultato desiderato, quindi il tuo codice di test sarà in grado di testare il metodo mailService.SendEMail () . Come puoi vedere, devi simulare un risultato che proviene da un'altra dipendenza che è un oggetto di classe ErrorService (oggetto dipendenza esistente).

Uno stub , in questo contesto, significa un'implementazione fittizia.

Cioè, un'implementazione semplice e falsa che è conforme all'interfaccia e deve essere utilizzata per i test.

I termini di Layman, sono dati fittizi (o dati falsi, dati di test ... ecc.) Che puoi utilizzare per testare o sviluppare il tuo codice fino a quando tu (o l'altra parte) non sei pronto a presentare / ricevere dati reali. È il "Lorem Ipsum" di un programmatore.

Database dipendenti non pronto? Creane uno semplice con Jane Doe, John Doe ... ecc. API non pronta? Creane uno falso creando un file .json statico contenente dati falsi.

In questo contesto, la parola "stub" è usata al posto di "mock", ma per motivi di chiarezza e precisione, l'autore avrebbe dovuto usare "mock", perché "mock" è una sorta di stub, ma per testare. Per evitare ulteriore confusione, dobbiamo definire cos'è uno stub.

Nel contesto generale, uno stub è un pezzo di programma (tipicamente una funzione o un oggetto) che incapsula la complessità di invocare un altro programma (solitamente situato su un'altra macchina, VM o processo - ma non sempre, può anche essere un locale oggetto). Poiché il programma effettivo da invocare di solito non si trova nello stesso spazio di memoria, invocarlo richiede molte operazioni come l'indirizzamento, l'esecuzione dell'effettiva invocazione remota, il marshalling / serializzazione dei dati / argomenti da passare (e lo stesso con il potenziale risultato), forse anche occuparsi di autenticazione / sicurezza e così via. Si noti che in alcuni contesti, gli stub sono anche chiamati proxy (come i proxy dinamici in Java).

Un mock è un tipo di stub molto specifico e restrittivo, perché un mock è una sostituzione di un'altra funzione o oggetto per il test. In pratica usiamo spesso i mock come programmi locali (funzioni o oggetti) per sostituire un programma remoto nell'ambiente di test. In ogni caso, il mock può simulare il comportamento effettivo del programma sostituito in un contesto ristretto.

I tipi più famosi di stub sono ovviamente per la programmazione distribuita, quando è necessario richiamare procedure remote ( RPC ) o oggetti remoti ( RMI , CORBA ). La maggior parte dei framework / librerie di programmazione distribuiti automatizza la generazione di stub in modo da non doverli scrivere manualmente. Gli stub possono essere generati da una definizione di interfaccia, scritta con IDL per esempio (ma puoi anche usare qualsiasi linguaggio per definire le interfacce).

Tipicamente, in RPC, RMI, CORBA e così via, si distinguono gli stub lato client , che si occupano principalmente del marshalling / serializzazione degli argomenti e dell'esecuzione dell'invocazione remota, e gli stub lato server , che si occupano principalmente di unmarshaling / deserializzazione gli argomenti ed effettivamente eseguire la funzione / metodo remoto. Ovviamente, gli stub del client si trovano sul lato client, mentre gli stub del server (spesso chiamati skeletons) si trovano sul lato server.

Scrivere buoni stub efficienti e generici diventa piuttosto difficile quando si tratta di riferimenti a oggetti. La maggior parte dei framework di oggetti distribuiti come RMI e CORBA si occupano di riferimenti a oggetti distribuiti, ma è qualcosa che la maggior parte dei programmatori evita ad esempio negli ambienti REST. In genere, negli ambienti REST, i programmatori JavaScript creano semplici funzioni stub per incapsulare le invocazioni AJAX (la serializzazione degli oggetti è supportata da JSON.parsee JSON.stringify). Il progetto Swagger Codegen fornisce un ampio supporto per la generazione automatica di stub REST in varie lingue.

Lo stub è una definizione di funzione che ha il nome della funzione corretto, il numero corretto di parametri e produce un risultato fittizio del tipo corretto.

Aiuta a scrivere il test e serve come una sorta di impalcatura per rendere possibile l'esecuzione degli esempi anche prima che il progetto della funzione sia completo

Hai anche un ottimo framework di test per creare un tale stub. Uno dei miei preferiti è Mockito C'è anche EasyMock e altri ... Ma Mockito è fantastico dovresti leggerlo - pacchetto molto elegante e potente

Questa frase è quasi certamente un'analogia con una fase nella costruzione di una casa - "spegnere" l'impianto idraulico. Durante la costruzione, mentre i muri sono ancora aperti, viene inserito l'impianto idraulico grezzo. Ciò è necessario affinché la costruzione continui. Poi, quando tutto intorno è abbastanza pronto, si torna indietro e si aggiungono rubinetti e servizi igienici e il prodotto finale effettivo. (Vedere ad esempio Come installare uno stub-out idraulico .)

Quando si "stub out" una funzione in programmazione, ne si crea abbastanza per aggirarla (per testare o scrivere altro codice). Quindi, torni più tardi e lo sostituisci con l'implementazione completa.

Stub RPC

• Fondamentalmente, uno stub lato client è una procedura che guarda al client come se fosse una procedura server richiamabile.
• Uno stub lato server guarda al server come se fosse un client chiamante.
• Il programma client pensa di chiamare il server; infatti, sta chiamando lo stub del client.
• Il programma server pensa di essere chiamato dal client; infatti, viene chiamato dallo stub del server.
• Gli stub si inviano messaggi l'un l'altro per realizzare l'RPC.

fonte

"Interrompere una funzione significa scrivere quanto basta per mostrare che la funzione è stata chiamata, lasciando i dettagli per dopo quando si ha più tempo."

Da: SAMS Insegna a te stesso C ++, Jesse Liberty e Bradley Jones