TDD e ADO.NET Entity Framework

Question

Di recente ho giocato con ADO.NET Entity Framework e trovo che si adatti alle mie esigenze per un progetto che sto sviluppando. Trovo interessante anche la sua natura non invasiva.

Dopo aver generato un modello di dati da un database esistente, devi affrontare il compito di integrare il modello generato e la tua logica aziendale. Più specificamente, sono abituato a testare l'integrazione delle mie classi che interagiscono con l'archivio dati tramite mock / stub delle interfacce DAL. Il problema è che non è possibile farlo utilizzando ADO.NET Entity Framework perché le entità che genera sono classi semplici senza interfaccia.

La domanda è: come posso applicare un approccio TDD allo sviluppo di un'applicazione che utilizza ADO.NET Entity Framework? È possibile o dovrei migrare verso un altro set di strumenti di generazione DAL?

Answer 1

Una delle grandi critiche a Entity Framework è stata che è intrinsecamente difficile testarlo, ad esempio in ALT.Net Vote of No Confidence quotato dal gef.

Ecco un post sul blog che illustra come aggirare questo problema ed essere in grado di testare il codice senza colpire il database, quando si utilizza Entity Framework.

Se la testabilità è una grande preoccupazione, potresti voler esaminare un altro framework ORM, come NHibernate, almeno fino al rilascio di Entity Framework 2.0.

Answer 2

Sebbene alla domanda originale sia stata data una risposta, mi sento di aggiungere qualcosa:

Attualmente sto utilizzando Entity Framework 4.0 su un sito Intranet che sto costruendo. Sono in grado di testare tutto nella mia logica aziendale e controller senza una connessione al database utilizzando il supporto POCO che è stato aggiunto.

Sebbene, i POCO possano essere generati dal nuovo modello t4 incluso in VS 2010, qualcosa che non sono stato in grado di trovare in VS 2010 è un modello t4 per generare il contesto dell'oggetto (il contesto dell'oggetto funziona fondamentalmente come un costruito in unità di lavoro per EF ed è essenziale per mappare i tuoi oggetti EF su POCO). Fortunatamente Joachim Lykke Andersen nel suo post sul blog Entity Framework 4.0 Beta 1 & # 8211; POCO, ObjectSet, Repository e UnitOfWork hanno scritto un modello t4 per generarlo ed è stato molto utile. Se si persegue una soluzione utilizzando EF4 che è testabile senza una connessione al database, consiglio vivamente di implementare qualcosa di simile alla sua soluzione che includa un repository generico, un'unità di lavoro wrapper e un'unità di fabbrica di lavoro. È stato molto utile.

Buona fortuna.

Answer 3

Concordo sul fatto che la versione 1 di Entity Framework è un crimine contro il design e ha sicuramente ottenuto il mio voto senza fiducia. Rendo onore al team del prodotto EF per aver riconosciuto l'errore e risposto aprendo il loro processo di progettazione alla comunità. La prossima versione non sarà perfetta, potrebbe non essere nemmeno pronta per l'uso in un'applicazione a livello di produzione, ma penso che finalmente stiano iniziando a capire cosa è importante per quelli che sanno che un cattivo design è un cattivo affare. Detto questo ... Sono ancora sospettoso. Il feedback continuo in fase di progettazione è nuovo per questi ragazzi e ho letto alcune dichiarazioni sul blog ADO.NET che sollevano bandiere rosse luminose. Vedremo come andrà con il rilascio di .NET 4.0.

Sembra che ci stiano provando:

Soluzione guidata dallo sviluppo guidato dai test con Entity Framework 4.0

Answer 4

  

" L'accoppiamento stretto della persistenza   infrastruttura per le classi di entità   elimina in gran parte la capacità di   utilizzare in modo efficiente feedback molto stretto   cicli sulla logica aziendale con   test automatizzati. Nella sua corrente   stato, le classi di entità EF non possono essere   efficacemente testato in modo indipendente   del database.

     

L'efficienza dell'unità automatizzata   test di oggetti comportamentali è   in gran parte una questione di quanto sia facile   i meccanismi di impostazione dei dati di test sono e   quanto velocemente i test possono essere eseguiti.   Utilizzando il database effettivo farà   configurazione dei dati di test più laboriosa,   introdurre dati per soddisfare le relazioni   vincoli che non sono germani   il test e rendere l'esecuzione del test an   ordine di grandezza più lento.

     

La capacità di una squadra di fare evolutiva   progettazione e consegna incrementale è   danneggiato da Entity Framework   disattenzione al software fondamentale   principi di progettazione come Separazione di   . Preoccupazioni "

Evidentemente rubato da qui: http://efvote.wufoo.com / forme / ado-net-entity-framework-voto-di-sfiducia /

Answer 5

Se stai osservando specificamente gli strumenti di generazione DAL, avrai difficoltà a integrarlo con TDD. La maggior parte degli strumenti di generazione dal che conosco generano anche i tuoi oggetti business e li accoppiano strettamente al DAL, rendendo difficili i test.

Puoi guardare gli strumenti di mappatura OR come nHibernate e forse Linq a sql che abilitano "l'ignoranza di persistenza", puoi definire i tuoi oggetti di business da soli e non hanno collegamenti al DAL o ad altri codici di infrastruttura. Ciò rende molto più semplice il test della logica aziendale separata dal database. Ho scoperto che abilita anche altri scenari come client occasionalmente connessi molto meglio.

Answer 6

Questa risposta è stata cambiata in " Sì, puoi " ;.

Puoi generare POCO e interfacce usando modelli T4 personalizzati come https://entityinterfacegenerator.codeplex.com/, quindi creare oggetti beffardi per testare dentro e fuori l'EF senza colpire il database.