Come posso rendere il codice vincolato a un ORM testabile?

L'unità che verifica il codice basato sul tuo DAL dovrebbe essere semplice: usa il repository schema per disaccoppiare il livello aziendale dal tuo ORM. Fornisci i tuoi POCO da un repository astratto, quindi puoi fornire un repository "reale" in produzione (che utilizza il tuo ORM), o un repository finto a scopo di test che fornisce solo POCO di test-data senza alcun accesso a DB. L'utilizzo di un ORM che funziona con POCO qui ha il vantaggio di poter facilmente creare quegli oggetti in memoria, senza la necessità di fare affidamento sull'ORM.

Una domanda diversa è come testare automaticamente metodi come "AddCustomer", supponendo che questo metodo contenga solo il codice relativo al database o all'ORM. Avendo un breve sguardo nella documentazione e nel codice sorgente di PetaPoco, sembra supportare solo un database con capacità in memoria: SqlLite. Quindi immagino che potresti configurare un'istanza SqlLite leggera per i tuoi dati di test e scrivere i tuoi test in questo modo.

In teoria, è possibile farlo anche con un sistema di DB relazionali in piena regola come Oracle o MS SQL Server, ma questa opzione è spesso troppo lenta e necessita di un sovraccarico amministrativo per essere pratica. Se vuoi comunque provare questa rotta, ti suggerisco di dare un'occhiata a DBUnit.NET , che supporta questo approccio.

Qualunque cosa tu faccia, potrebbe essere una buona idea separare questi due casi nel tuo codice: scrivi (1) codice estraendo gli oggetti necessari dal tuo DB in memoria, e (2) separati codice per fare la logica di business, senza alcun accesso a DB. Sicuramente avrete bisogno del (3) codice che gestisce (1) e (2) per farli funzionare insieme, ma (1) e (2) potrebbero essere testati quindi più facilmente in isolamento.

Guarda in Mock Objects e Injection dipendenza.

Gli oggetti fittizi sono un modo utile per scrivere test unitari per oggetti che fungono da mediatori. Invece di chiamare gli oggetti del dominio reale, l'oggetto testato chiama un oggetto dominio fittizio che si limita ad affermare che i metodi corretti sono stati chiamati, con i parametri previsti, nell'ordine corretto.

Iniezione di dipendenza consente di testare una classe in isolamento, ad esempio immagine di una classe con 5 membri privati, questi oggetti sono inizializzati nel costruttore. Ora il test unitario di questa classe e dei suoi metodi eseguirà anche il codice relativo ad altri oggetti, questo vanifica lo scopo del test unitario. L'iniezione delle dipendenze consente al chiamante di passare nei 5 oggetti inizializzati e il costruttore li assegna semplicemente ai membri privati, ad esempio. Ciò significa che posso passare in MockDB ad esempio quando il test dell'unità, ma per il codice di produzione, passa nel vero oggetto DB concreto.

Ho usato PetaPoco in un'applicazione e quello che ho finito è stato semplicemente l'astrazione di un'interfaccia per l'oggetto Database che ha appena esposto i metodi che uso effettivamente (poiché ce ne sono 100 e ho solo bisogno effettivamente di 10-15 ).

Questo mi ha permesso di fornire finte implementazioni di quell'interfaccia nei test unitari e nel mio contenitore DI ho semplicemente legato l'oggetto Database all'interfaccia IDatabase.

Non mi preoccuperei di implementare il pattern del repository, ma l'astrazione di un'interfaccia IDatabase diventerà essenzialmente un repository generico.

Il conseguente fastidio di questo mi ha portato a creare il mio Micro-ORM (MicroLite) che è stato progettato per consentire la facilità di test che puoi trovare su GitHub e NuGet (nota: al momento supporta solo MsSql).