How to mock with LLBLGen

Question

How can you mock LLBLGen? I see that there is an ILinqMetaData interface but it doesn't provide any useful methods to mock out. I'm assuming you would want to program to the ILinqMetaData interface as well as the generated entity interfaces to keep objects loosely coupled to the data. Does anyone have any examples of simple tests/mocks?

Ages ago I know.. but did you ever find an answer to this? I'm trying to mock the Database and LinqMetaData classes now as well. I can fake ILinqMetaData, but I want it to return mocked data and cant get my head around how. — crthompson, Jun 03 '19 at 23:17
@paqogomez I don't really remember but I think when you generate the entities, you can have it generate interface templates and stuff along with it. I'll see if I can do some digging and remember how we did that... but don't get your hopes up — Joe Phillips, Jun 04 '19 at 00:14
Thanks for the looking. I have already generated interfaces for the entities. My issue is that LinqMetaData returns `Database` and I need to mock the `Database` class. I'm not out of ideas, but I'm a bit hogtied by the architecture of the app too. Anything will help, thanks. — crthompson, Jun 04 '19 at 14:58
@paqogomez I think we just ended up using repositories and wrapped the llblgen stuff inside — Joe Phillips, Jun 04 '19 at 15:02

score 1 · Answer 1 · edited May 23 '17 at 11:44

1

I think it's not limited to LLBLGen, maybe this can help:

What's the best strategy for unit-testing database-driven applications?

Personally, I don't normally test my database access or repositories, just the logic that operates on the entities, or integration tests that operate on the entire stack (including the DB).

UPDATE: does this help? it allows you test your logic by mocking the IOrderRepository without having to do any fetch/persistence logic:

public class MyBusinessLogic 
{
    IOrderRepository orders;

    public MyBusinessLogic(IOrderRepository orders) 
    {
      this.orders = orders; 
    }

    public DoSomethingTestable(OrderEntity order)
    {
      order.Total = 100;
      orders.Save(order);
    }
}

edited May 23 '17 at 11:44

Community

1
1

answered Jun 18 '12 at 21:19

Wiebe Tijsma

10,173
5
52
68

We are using the Self Servicing paradigm and therefore the entities are tied to the database. I'm trying to figure out how to get around that. – Joe Phillips Jun 26 '12 at 20:10
Hmmm self-servicing wouldn't be my first choice if I wanted API flexibility... Self-servicing is to abstract away the data access anyway, and you have to be able to assume it works, so shouldn't your concern be about the logic that operates on the entities regardless of whether the data is persisted/fetched? – Wiebe Tijsma Jun 27 '12 at 12:10
Yes, but if I want to update an "Order" object and persist it, do I write a function to update only the specific pieces of information I want or can I use dirty bits or something? Ideally I could just use the Entity objects as my data holders in my business logic. – Joe Phillips Jun 27 '12 at 18:53
Well you could write logic in a class that modifies an entity that's passed in, then passes it to a (mocked) repository to save, then check if that entity contains the expected modifications? – Wiebe Tijsma Jun 27 '12 at 20:15
Yes, I would essentially be rewriting the logic that is already in the Entity class. I was hoping to avoid that but if it's not possible, then it's not possible – Joe Phillips Jun 27 '12 at 21:01
I don't think so, I assume you're coupling persistence/fetching logic in your entities? If you want to be sure ask your question on the LLBLGen Pro forum too http://www.llblgen.com/tinyforum/ – Wiebe Tijsma Jun 28 '12 at 13:37

How to mock with LLBLGen

1 Answers1