Ok,

I am trying to think through how I would test an application that I build with NHibernate.

You are supposed to not write code until you have a test that fails. So assuming I want to start with the DomainModel, are you writting tests that ensure that your domain objects persist properly.

Generally you only unit test behaviors, right?

Perhaps I am having a hard time with this cause this is the first ap I have used unit testing with, and NHibernate with.

Any tips would be appreciated.

Thanks,
PilotBob

From one OO theoretical perspective, the Domain classes do not "persist" any data. Rather they are POCO objects that simply represent the data model. It is the DAOs (or DTOs) that persist data and retrieve data.

So, if you agree with this model, then you don't really need to write unit tests for the POCO objects (although I have to find stoopid mistakes like having a public property return the wrong member variable). You would write unit tests for the DAOs. That is where your TDD would start.

So maybe you have a Domain namespace with a Member class. Then you have a DAO namespace with a MemberDAO class. Member unit tests could be simple things like:



Then in your MemberDAOTest class you might do:


So to make a long answer short, yes, just test your business methods. Test the persistability for each object within your DAO tests. It isn't necessary to Unit Test the POCO objects (although I do).

Just one developer's opinion.

-devon

Here you have another view. You should only test things that may break, and usually people advise against testing getters and setters, because there's nothing in there that can break (if they are trivial of course). When you test persistence code, you shouldn't focus on testing simple NHibernate usage like CRUD of a single object, but more on whether your mapping is right, cascades are not violating foreign keys, all the lazy-loaded data you are going to need is actually loaded before the session is closed, etc.

I have some fairly simple tests here for example, that check the number of properties in a class and number of mapped properties and if they differ, report an error.

Of course, if you find something untested that breaks, you should write a test for it so that it doesn't break again.

I was going to post a similar question about what to unit test, but decided I should search the forums a bit more before hand. Any way now that PilotBob (!) has posted I thought I'd jump in with my own questions / thoughts.

I've recently become a little jaded over all the tedious unit tests I've written in the past that verify the (hand written) code that maps xml to domain object and vice versa. Ok, so these tests are a necessary evil as the code is hand written. However, now I find this great framework that, for future projects, is going to do the mapping for me (I'm abandoning the xml-to-object mapping in favour of ORM). The benefit of a framework is that I should be able to rely on it to do the heavy lifting in a tried and proven way - this will cut down on the tests I have to write to prove the mechanics (as per the replies to this topic).

Now I come to a delimar - do I drive the existence of my POCO objects by writing unit tests or do I simply take a tool like ObjectMapper and create my POCO classes from the database. This will also create my mapping files for me. So it seems to me I don't have to write all those borring tests 'cause I can rely on the combination of ObjectMapper and NH - in short I've saved myself probably a week (or more) worth of work.

As per sergey, I write some tests for the curly situations (cascades are not violating fks, etc), but it seems to me these tests are going to get written after the production code. Is this what happens in most people's experience?

Maybe, my next project will already have a legacy database that was not written with an OO perspective. So instead I drive the creation of my POCO objects from unit tests which I then need to map. Do I drive the creation of my mapping files using Unit tests or do I work in broader strokes and use the ObjectMapper tool to graphically map from DO to database. If its the later then I'm assuming that the acceptance tests, or unit tests written after the fact, will pick up any mapping problems.

Does this sound all reasonable or does it look as though I would be slipping back into my old ways of using "evil" wizards rather than writing test first?

Thanks
Christian