Imagine an Order that has a relationship with a Customer.

LLBL generates a Order class, with a Customer property.

Is it possible to modify the return type of the Customer property to ICustomer? (Customer implements ICustomer)

If this is possible, it would make my testing life much easier. (I believe I can't use converters for this purpose)

Any tips/help would be appreciated!

No you can't easily. Please elaborate more on what you need, maybe we can found a workaround

When the return type of the property is an interface, I can use my own test entities. I don't want to hit the database when testing, so I've created some hard-coded entities.

So I want to have code like this:

ICustomerEntity customer = new CustomerEntityTest();

this line itself is not a problem, but when the Order property is being read, it fails. Because customer.Order has the concrete OrderEntity type which will be fetched from the database, where I also want it to return an interface.

I'm curious of your thoughts on this...

It's not that easy to introduce this (as in: you have to modify the template). Are you using adapter or selfservicing? I think testing with surrogates instead of the real code isn't really helpful, so IMHO it's best to simply prevent the db fetch to occur instead. Or even better: simply do test on a db, which is empty or filled with test data. (as that will mimic real-life scenarios and makes testing more valuable)

In adapter, it is doable to override the Execute... methods to intercept the IRetrievalQuery instances and create your own (by creating a dummy dbcommand which produces a dummy datareader which returns dummy data)

But that might be a lot of work, compared to simply pointing it to a testdb.

Hmm. I don't like hitting the database. It is slow and I have to maintain two databases. Aside from this discussion, it seems I don't really have a choice do I? (I'm currently using Self Servicing...)

It sounds pretty cumbersome to achieve this?! I'm not a big fan of modifying the template.

Note: at the moment, I don't have time to experiment with Adapters, but I have a gut feeling this could be a better fit for me. I don't have to support other databases, but it might facilitate testability am I right?

Jowen wrote:

Hmm. I don't like hitting the database. It is slow and I have to maintain two databases. Aside from this discussion, it seems I don't really have a choice do I? (I'm currently using Self Servicing...)

It sounds pretty cumbersome to achieve this?! I'm not a big fan of modifying the template.

You're looking at a hierarchy of classes nested inside eachother: so customer.Orders returns IOrderEntity, but that IOrderEntity has an IEmployeeEntity instance reference which contains a list of IEmployeeEntities as well. Who's going to instantiate these instances if you're not going to the db?

Note: at the moment, I don't have time to experiment with Adapters, but I have a gut feeling this could be a better fit for me. I don't have to support other databases, but it might facilitate testability am I right?

You can mock the IDataAccessAdapter interface and thus not have to go to the db, but the same question stands: if you want real objects in a hierarchy/graph to work with, you need to build these somewhere.

And besides... your code might 'work' (as in: tests run) but that doesn't mean the code works on a database as filters might have been applied etc. etc. I.o.w.: if your goal is to test your code if it works, use a real db. You don't have to maintain two databases: we have templates which generate a DDL SQL script (see customer area -> v2.6 -> Tasks and templates) so you can apply that if something changes.