Unit testing the code relying on your DAL should be straight-forward: use the repository pattern to decouple your business layer from your ORM. Provide your POCOs by an abstract repository, then you can either provide a “real” repository in production (which uses your ORM), or a mock repository for testing purposes which delivers just test-data POCOs without any DB access. Using an ORM which works with POCOs here has the advantage that you can easily create that objects in memory, without the need to rely on the ORM.

A different question is how to automatically test methods like “AddCustomer”, assumed that this method contains only database or ORM related code. Having a short look into the PetaPoco documentation and source code, it seems to support just one database with in-memory capabilities: SqlLite. So I guess you could set up a lightweight SqlLite instance for your testdata and write your tests against this.

Theoretically, you could do this also with a full-blown relational DB system like Oracle or MS SQL server, but that option is often too slow and needs too much administrative overhead to be practical. If you want trying this route anyway, I suggest you have a look at DBUnit.NET, which supports this approach.

Whatever you will do, it may be a good idea to separate those two cases in your code: write (1) code pulling the needed objects from your DB into memory, and (2) separate code for doing the business logic, without any DB access. Surely you will need (3) code that manages (1) and (2)to make them work together, but (1) and (2) could be tested then more easily in isolation.

Look into Mock Objects and Dependency Injection.

Mock objects are a useful way to write unit tests for objects that act as mediators. Instead of calling the real domain objects, the tested object calls a mock domain object that merely asserts that the correct methods were called, with the expected parameters, in the correct order.

Dependency injection allows you to test a class in isolation, for example image a class with 5 private members, these objects are initilised in the constructor. Now unit testing of this class and its methods will also be running code concerned with other objects, this defeats the purpose of unit testing. Dependency injection allows the caller to pass in the 5 initialized objects and the constructor simply assigns them to the private members for example. This means I can pass in MockDB for example when unit testing, but for production code, pass in the real concrete DB object.

I’ve used PetaPoco in an application and what I ended up doing was just abstracting an interface for the Database object which just exposed the methods that I actually use (since there are 100s of them and I only actually needed 10-15).

This allowed me to provide mock implementations of that interface in unit tests and in my DI container I simply bound the Database object to the IDatabase interface.

I wouldn’t bother implementing the repository pattern, abstracting an IDatabase interface will essentially become a generic repository anyway.

The resulting annoyance with this led me to create my own Micro-ORM (MicroLite) which is designed to allow ease of testing which you can find on GitHub and NuGet (note: at present it only supports MsSql).