TypeMock gets it wrong on ORM
The fellas at TypeMock recently discussed “Mocking only what you own” in response to a cogent though not very helpful post from normally lucid author Mark Needham.
Mark basically said don’t mock external dependencies SUCH AS Hibernate. Not any external dependency. Without getting into the functional versus unit/mock testing discussion I agree with Mark. Why write tests for an ORM. It should work. That’s why we use ORM’s.
The TypeMock guys butchered the whole thought though suggesting that Mark should have a DAL that Hibernate uses. Isn’t the beauty of ORM’s that is generates the DAL for you? I really don’t know where they are coming from with these thoughts – but it’s not helpful from a company that makes mocking/type isolator frameworks.
My advice to TypeMock: take a stand. Say it should be done one way or another, or, if you don’t understand ORM’s like hibernate don’t speak on it.
1 comment so far
Leave a reply
I would never mock the Orm, I would, however, use patterns such as repository and mock Dal read/writes at the repository level.
Then in my concrete implementation of my repository I can use NHibernate. Otherwise I am creating integration tests!
Mocking an ORM framework would be a nightmare. However the statement “Mocking what you own” doesn’t support unit testing well. If I was to have a 3rd party library which utilises a blocking method taking possibly 30 seconds how do I get decent test turnaround times?
There is a research project at Microsoft at the moment which uses a stub and moles to create mole types for the aforementioned scenario. This removes the ownership requirement for unit testing.