Evita la dipendenza dal database per il test dell'unità senza simulazione

Question

Ho molti oggetti con metodi che richiedono l'accesso al database. Stiamo cercando di entrare nei test unitari ma siamo desiderosi di evitare l'uso di oggetti finti se possibile. Mi chiedo se ci sia un modo per refactoring il metodo Validate mostrato di seguito in modo che non avrebbe bisogno di accesso db. Nell'applicazione attuale di solito c'è un bel po 'di più, ma penso che questo esempio semplificato dovrebbe essere sufficiente.

Impareremo a utilizzare gli oggetti mock se ne abbiamo bisogno ma sembra solo un sacco di spese generali, quindi sto cercando alternative.

public class Person 
    { 
     public string Name; 

     public string Validate() 
     { 
      if (PersonDA.NameExists(Name)) 
      { 
       return "Name Already Used"; 
      } 

     } 
    } 

Answer 1

Personalmente mi piacerebbe solo andare il percorso dell'oggetto finto. È molto più flessibile e sembra che tu voglia seguire la strada per inserire il codice di prova nel tuo oggetto reale?

Regarless, estrae il codice di convalida in un oggetto PersonValidator con un metodo per boolean isValid (Person). Quindi nel codice di test utilizzare un simulatore di validazione che restituisce true o false in base al caso di test.

Answer 2

Si dovrebbe semplicemente impostare un database che viene utilizzato per il test dell'unità. Se si usano i prototipi per l'accesso ai dati, non si testerebbe molto? :)

Answer 3

Dai uno sguardo allo dbunit, è impostato appositamente per popolare un piccolo database di test in modo da poter utilizzare i tuoi oggetti reali su un database fittizio durante il test dell'unità. Testare con esso è molto più semplice dello sviluppo di oggetti mock, molto più sicuro della modifica del codice di accesso ai dati e molto più approfondito di entrambi.

Answer 4

La classe Person è difficile da testare in quanto ha una dipendenza statica nascosta dal codice di accesso al database. Puoi rompere questo accoppiamento introducendo una collaborazione dinamica tra la Persona e qualche nuovo tipo di oggetto che le fornisce le informazioni necessarie per convalidarne lo stato. Nei test di unità della persona è possibile verificare ciò che accade quando è valido o non valido senza colpire il database passando le implementazioni dell'oggetto "stub" del suo collaboratore.

È possibile testare l'implementazione reale, che colpisce il database, in un set separato di test. Questi test saranno più lenti ma dovrebbero essercene meno perché saranno traduzioni dirette dei metodi accessor alle query di database senza una propria logica complessa.

Se lo si desidera, è possibile chiamarlo "utilizzando oggetti fittizi", poiché il design corrente indica solo la necessità di interrompere query, non di prevedere comandi, un framework di oggetti fittizi è uno strumento troppo complicato per il lavoro. Gli stub scritti a mano renderanno i test più facili da diagnosticare.

Answer 5

Perché stai cercando di evitare esattamente i salti? Se hai intenzione di esercitarti con i test delle unità e hai un codice di accesso ai dati, sarà più facile mettersi a proprio agio con il modo di fare finta/falsificare/iniettare dati.

Se è perché non si desidera introdurre un framework di simulazione, è possibile codificare alcuni semplici stub in base alle proprie esigenze.

Inserire il codice di accesso ai dati dietro un'interfaccia consentirà di evitare la necessità di un database. Prendi in considerazione l'utilizzo di dependency injection per inserire il codice di accesso ai dati di simulazione o stub durante i test.