This project is read-only.

Unit Testing Recommendations?

Jan 20, 2012 at 3:25 PM

When using the EntityPersistor just by setting a Navigation Property, the associated Id property is automatically set and the domain object is added as an item in the necessary collection of the other object.

However, using the InMemoryPersistor for Unit Testing, this auto association mechanism does not occur.

What is the recommended practice?  I feel that to get my tests working correctly I explicitly associate related objects in code but would like to hear other opinion and suggestions on how to handle all of this?


Jan 20, 2012 at 3:38 PM

I don't know of an easy option, here.  As you have found out, the one big difference between running with EF vs. the InMemory persistor is that the latter does not automatically maintain reverse associations  -  you have to do it manually.  You can write methods your code (making more use of Modify and Clear methods for example) to maintain those manually and this should have no negative impact when running with EF  -  though you do sometimes have to be carefulm especially when associating an object being persisted with an already persistent one (you can get errors wherein EF protests that you are trying to do an illegal association).

We have thought about trying to make InMemory work identically to EF in this respect, but it is really too much work for us to be worth it.

Another option that I am thinking about would be (for testing purposes) to work with an EF-compatble in-memory database as the database (i.e. not bother with the Naked Objects InMemoryPersistor at all).  I haven't tried this approach yet  -  the last time I looked into it (for a few minutes only) I was put off by statements that SQLServer CE didn't support auto identity assignment (of keys), which would defeat the objective.  But that information might be wrong or out-of-date, and there might be other EF-compatible in-memory databases available now.

Jan 20, 2012 at 3:56 PM

Thanks for the info.

Have already started writing update methods to set properties and associations manually.  Think I'll continue along this path for now as its probably better to handle associations manually to ensure that my app doesn't have a tight coupling to EF.

Hopefully I won't get bitten by EF, and if I do, it should occur early on in development, in which case I will re-evaluate my approach.


Jan 20, 2012 at 4:11 PM

Even if you do hit the issues I referred to, they're not too difficult to accommodate  -  so post here if you hit one. The message is along the lines of 'trying to associate a not persisted object with a persisted one'.

Jan 23, 2012 at 9:44 AM

Hi Richard,

I have just been digging around and found the ADO.Net C# POCO Entity Generator t4 template.

This template generates POCO domain objects and also generates code to ensure the opposite ends of relationships are kept in sync.

I have just played about with modifying it to support the NakedObject attributes and was going to try this for ensuring that my domain model is accurate when unit testing.

I'll let you now how I go.

At the bottom of the article referenced above they list known issues with this approach.  Are any of these major show stoppers in your opinion in relation to NakedObjects?


Jan 23, 2012 at 10:31 AM


I don't have time to look into the specifics of what they are doing with that template.  But the idea of using the T4 template to generate code that looks after bi-directional association in a persistence-ignorant fashion seems sound to me.  So please do let us know how you get on.

(Once you have the technique working, it would be nicer to merge it into our own T4 template, so you get the Naked Objects conventions also).