There is a more fundamental issue here. You seem to be heading to a
case where you get the worst of both worlds. You don't want to do
state based testing, instead you prefer behavior based testing ...
this is ok except that you have not put any behavior on your
interface.

with an interface like

> public interface ICategory
> {
>    int Id { get; set; }
>    string Name { get; set; }
>    IGroup Group { get; set; }
> }

There is nothing to mock, this is data not behavior. "Mocking" data is
the same thing as just setting it to some value which can be done
without the "mocking" idea... you are creating state based testing in
your mocks.

This taking a bit from both sides creates something much worse than
what either side offered to begin with. Instead either mock the
repository to return you non-nh provided data objects (which I believe
has been recommended) or make your interfaces behavioral where
behavioral tests make sense. I won't assign a value judgement to which
of those is better (I think people know my beliefs there already) but
I will say they are both better than what you are discussing.

Cheers,

Greg

On Fri, Apr 30, 2010 at 3:23 PM, robinsonpr <[email protected]> wrote:
> Hi,
>
> I have what should be a relatively simple issue but I am struggling to
> resolve it.
>
> There are 2 tables in my data model: Group and Category. There is a
> one-to-many relationship....one Group can have many Categories, and a
> Category can be in one group.
>
> I've got the same 2 classes in my domain model, standard stuff.
>
> Now, I need to write some unit tests for a controller class which uses
> instances of Group and Category. But the key here is that they are
> unit tests so I would use a mocking framework (NMock2 in this case) to
> create mock instances of the domain objects.
>
> So standard practice is to have your domain objects implement an
> interface, and use the interface to create the mock instances.
>
> So I created an IGroup and ICategory. ICategory has an accessor for
> it's group. Now I'm working with interfaces the ICategory.Group
> returns an IGroup rather than a group:
>
>
> public interface ICategory
> {
>    int Id { get; set; }
>    string Name { get; set; }
>    IGroup Group { get; set; }
> }
>
>
>
> This is all fine and my unit tests with the mock instances of
> ICategory and IGroup all work fine.
>
> HOWEVER....now I am unable to do any data access with the Category and
> Group objects...I get the following NHibernate error:
>
> "NHibernate.MappingException: An association from the table CATEGORY
> refers to an unmapped class: CLEDOM.Business.Domain.IGroup."
>
>
>
> Here's my mapping file for Category:
>
> <?xml version="1.0"?>
> <hibernate-mapping xmlns="urn:nhibernate-mapping-2.2" auto-
> import="true" assembly="CLEDOM.Business">
>   <class name="CLEDOM.Business.Domain.Category" table="CATEGORY">
>      <cache usage="read-only"/>
>      <id name="Id" type="int" column="CategoryId">
>         <generator class="native" />
>      </id>
>      <property name="Name" type="string" column="Name" length="128" /
>>
>      <many-to-one name="Group" column="GroupId" />
>   </class>
> </hibernate-mapping>
>
>
>
> I tried to find some info on this but didn't really find a good
> example of a domain model implemented using standard interfaces. I did
> find some stuff but it had all sorts of IoC and Castle Windsor in
> there which was way over the top for what I want. I just want to use
> simple interfaces!
>
> I did find another sample which included a "proxy" attribute on the
> class element. So I tried this:
>
>
> <?xml version="1.0"?>
> <hibernate-mapping xmlns="urn:nhibernate-mapping-2.2" auto-
> import="true" assembly="CLEDOM.Business">
>   <class name="CLEDOM.Business.Domain.Category"
> proxy="CLEDOM.Business.Domain.ICategory" table="CATEGORY">
> ...
>
>
>
> but that made no difference.
>
> Can anybody help? Can my domain model be coded against interfaces?
>
> --
> You received this message because you are subscribed to the Google Groups 
> "nhusers" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> For more options, visit this group at 
> http://groups.google.com/group/nhusers?hl=en.
>
>



-- 
Les erreurs de grammaire et de syntaxe ont été incluses pour m'assurer
de votre attention

-- 
You received this message because you are subscribed to the Google Groups 
"nhusers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/nhusers?hl=en.

Reply via email to