Cos'è uno "Stub"?

Quindi, continuando con la mia risoluzione per il nuovo anno di entrare di più in TDD, ora sto iniziando a lavorare di più con Rhino Mocks .

Una cosa che tengo a fare è assicurarmi di capire davvero quello che sto facendo, quindi volevo verificare la mia comprensione di ciò che ho visto finora (e ho pensato che sarebbe stato bello portarlo qui come un risorsa).

Cos'è uno "Stub"?

Martin Fowler ha scritto un eccellente articolo su questo argomento. Da quell'articolo:

Meszaros usa il termine Test Double come termine generico per qualsiasi tipo di oggetto fittizio utilizzato al posto di un oggetto reale a scopo di test. Il nome deriva dalla nozione di controfigura nei film. (Uno dei suoi obiettivi era quello di evitare di utilizzare qualsiasi nome che fosse già ampiamente utilizzato.) Meszaros definì quindi quattro tipi particolari di doppio:

• Gli oggetti fittizi vengono passati in giro ma non vengono mai effettivamente utilizzati. Di solito vengono utilizzati solo per riempire elenchi di parametri.
• Gli oggetti falsi hanno effettivamente implementazioni funzionanti, ma di solito prendono qualche scorciatoia che li rende non adatti alla produzione (un database in memoria è un buon esempio).
• Gli stub forniscono risposte predefinite alle chiamate effettuate durante il test, di solito non rispondono affatto a nulla al di fuori di ciò che è programmato per il test. Gli stub possono anche registrare informazioni sulle chiamate, come uno stub del gateway di posta elettronica che ricorda i messaggi "inviati", o forse solo il numero di messaggi "inviati".
• I mock sono ciò di cui stiamo parlando qui: oggetti preprogrammati con aspettative che formano una specifica delle chiamate che ci si aspetta di ricevere.

Per dirla con parole mie: gli oggetti fittizi "si aspettano" che determinati metodi vengano chiamati su di essi e in genere fanno sì che uno unit test fallisca se le loro aspettative non sono soddisfatte. Gli oggetti stub forniscono risposte predefinite (e possono essere generati automaticamente dalle librerie helper), ma in genere non causano direttamente il fallimento dello unit test. In genere vengono utilizzati solo in modo che l'oggetto che stai testando ottenga i dati necessari per svolgere il suo lavoro.

Uno "stub" è un'implementazione di un'interfaccia che esiste per fornire dati / una risposta di qualche tipo. Per esempio:

• un DataSet
• elenco di utenti
• un file Xml

Normalmente questo sarebbe fornito da un altro servizio (sia esso Web Service, un'altra applicazione, un database) ma per migliorare la testabilità del codice, i risultati sono "falsificati".

Uno dei principali vantaggi di ciò è che consente di formulare asserzioni in unit test sulla base dei dati attesi. Se si verificano errori a causa di errori nei dati, è possibile aggiungere facilmente test, creare un nuovo stub (replicando l'errore dei dati) e produrre codice per correggere l'errore.

Gli stub differiscono dai Mock in quanto vengono utilizzati per rappresentare e testare lo stato di un oggetto, mentre un Mock verifica la sua interazione .

Credo che "stub" provenga da STartUpBlock. è usato per fare riferimento a parti di codice che vengono generate automaticamente per aiutare te, lo sviluppatore, a iniziare.

Uno "stub" o "metodo stub" è progettato per essere un codice di avviamento o un sostituto temporaneo per codice ancora da sviluppare. È un codice integrato generato da un IDE. I metodi stub sono in realtà metodi utilizzati per testare i metodi di una particolare classe. Viene utilizzato inserendo alcuni valori per le variabili locali nei metodi di sviluppo effettivi e controllando se l'output è corretto. È importante per trovare bug nel codice.

Ho affrontato la domanda di recente e ho riconosciuto questo confronto tra Stub e Driver è davvero chiaro e utile:

Fondamentalmente, stub e driver sono routine che in realtà non fanno nulla se non dichiarare se stessi ei parametri che accettano. Il resto del codice può quindi prendere questi parametri e usarli come input.

+ --------- + ------------------------------- + ------- ------------------------ +
| | Stub | Driver |
+ --------- + ------------------------------- + ------- ------------------------ +
| Tipo | Codici fittizi | Codici fittizi |
+ --------- + ------------------------------- + ------- ------------------------ +
| Usato in | Integrazione top-down | Integrazione dal basso |
+ --------- + ------------------------------- + ------- ------------------------ +
| Scopo | Per consentire il collaudo della tomaia | Per consentire il test della parte inferiore |
| | livelli del codice, quando il | livelli del codice, quando il |
| | i livelli inferiori del codice sono | i livelli superiori del codice sono |
| | non ancora sviluppato. | non ancora sviluppato. |
+ --------- + ------------------------------- + ------- ------------------------ +
| Esempio | A e B sono componenti. | A e B sono componenti. |
| | A ---> B | A ---> B |
| | | |
| | A è stato sviluppato. | A deve ancora essere sviluppato
| | B deve ancora essere sviluppato. | B è stato sviluppato. |
| | Pertanto, viene utilizzato lo stub | Pertanto, viene utilizzato il driver |
| | al posto di B per imitarlo. | al posto di A per imitarlo |
| | | |
| | A ---> Stub | Driver ---> B |
+ --------- + ------------------------------- + ------- ------------------------ +

Dalla differenza tra Stub e Driver

Dopo alcune ricerche e sulla base dei file stub che ho affrontato durante la mia vita di programmatore, direi che un file stub è solo un file che contiene l'intera o parte dell'implementazione di un file. Aiuta gli sviluppatori a iniziare a scrivere codice.