Unit testing datamodel : related entities

Question

I'm new to unit testing & TDD and after reading some articles i decided to start TDD in a small project of mine. it's a simple Theater Ticket Booking which uses NHibernate & also Repository pattern. i decided to first write some tests for my data model, so i started with simple CRUD operations on entities. the first problem that i faced was entities with many-to-one relations. for example i have a Show entity which has a many-to-one association to the Director entity (each Show has a Director), so for testing the Show.Create method i had to create a Director entity to assign him the Show first.

Since unit testing strongly discourage writing dependent tests, how could i get over this problem without making any dependency to such related entities?

Answer 1

I find it helps to think of TDD as writing an example of how to use something, and why the behavior is interesting.

So for instance, in your application you might have this behavior:

A show is associated with a director when it's created.

However, that's not very interesting. Why is this valuable? Where is it used? If you can show some aspect of behavior in which this is important, that's more interesting.

A show's reputation starts off with its director's reputation.

You can then write an example of this behavior:

Given a director with a reputation of 75%
When he creates a new show
Then the show should start with a reputation of 75%.

That would be more interesting behavior. We can actually create a show with that reputation, without using Hibernate. I sometimes put examples like this as comments in the test. (I'm using this as an example, since I have no idea why creating a show with a director is important to you!)

For something like NHibernate, either use full-stack scenarios that cover the entire application, or integration tests which just check the mappings by constructing a show with its director, or check manually that the application works. You can assume that NHibernate will continue to work if you're using it in the right way, so you need fewer tests around it compared to the code you're going to change.

My experience is that it's OK to create real domain objects (Show, Director, etc.) rather than mocking them out. However, if you have any complex calculations - for instance, perhaps there are complexities to calculating the reputation of a Show once it's been on for several nights - then you can inject a mock to help with that, and your behavior will change accordingly:

A show uses the reputation rules for its reputation

// Given the reputation rules
(mock out the reputation)

// When a show is created with a director
(create the show)

// And it's shown for 3 nights with varying reviews
(associate the reviews with the show)

// Then it should use the rules to calculate its reputation
(verify that when you get the reputation, the show asks the mock for help).

Hope this gives you an idea of where it might be useful to mock, and where it's likely that you don't have to. This becomes more natural the more you practice.