4

I'd like to write a unit test for my data access layer to make sure that everything works allright in it. The question is, what kind of things should I put into the tests?

The DAL is a static Repository class which hides the underlying layer (Fluent NHibernate) and exposes stuff to the public through an IQueryable.

I thought about

  • CRUD (Create/Retrieve/Update/Delete) operations
  • Transactions

Is there anything else about a DAL that is worth testing?
Thanks in advance for your answers!

Venemo
  • 18,515
  • 13
  • 84
  • 125

3 Answers3

12

Repository implementation is tested with integration tests, not unit tests. Isolating repository implementation (mocking ORM) is almost impossible. Please take a look at this answer. Integration test uses a real ORM combined with real or fake (usually in-memory) database to do following:

  • saving new object
  • change -> persist -> restore sequence
  • all 'Find' methods

Essentially you testing the correctness of:

  • mappings (even if you use fluent)
  • criteria
  • hql or sql queries

Transactions are usually handled by an application layer, not repositories. You might be interested in this answer. Encapsulating IQueryable in the repository implementation will make testing a lot easier for you.

Community
  • 1
  • 1
Dmitry
  • 17,078
  • 2
  • 44
  • 70
  • Why are you calling these "integration tests"? – Venemo Sep 18 '11 at 14:02
  • Because unit implies *isolation*. When you see 'unit' read **'isolated unit'**. Isolating repository implementation from NHibernate is almost impossible. So you need integration test that verifies that **combination of the repository and real ORM** work together. Please take a look at this: http://stackoverflow.com/questions/7110981/the-repository-itself-is-not-usually-tested/7111748#7111748 – Dmitry Sep 18 '11 at 14:07
  • Ah, yeah, you are correct. I've read that post, now I understand. – Venemo Sep 18 '11 at 14:16
  • Indeed I want to test the *combination of the ORM and the repository*, and not the *repository alone*. – Venemo Sep 18 '11 at 14:17
  • SQLite will not catch foreign key constraints, so there needs to be an integration test with the 'real' db too – Berryl Sep 18 '11 at 14:32
  • You can easily stub or mock the repository, but this only makes sense to do in unit tests where the repository itself is not the SUT. Excellent answer Dimitry. Cheers – Berryl Sep 18 '11 at 14:34
  • At the end I decided to use the test with a real DB, together with NHibernate's `hbm2ddl.auto`... it was effortless! Thanks @Dmitry and @Berryl – Venemo Sep 18 '11 at 18:47
1
  1. Need to test proper Exception handling
  2. Time Out Parameter of Database Connection
  3. Time Out Parameter of Store Procedure invocation
  4. Proper input parameters mapping . If store procedure expects to receive float but receive int.
Gregory Nozik
  • 3,296
  • 3
  • 32
  • 47
  • Thanks for the answer! My DB doesn't have stored procedures. But your points are still valid! – Venemo Sep 18 '11 at 12:20
1

Usually in a DAL you don't have business logic, just plain db access code which is probably 1-5 lines long, so there is not to much to test ...

If you are sure you want to unit test it then i believe CRUD is fine. Mock out NHibernate, provide fake data and test against that fake data ;).

Hope this helps ;)

Moszi
  • 3,236
  • 2
  • 22
  • 20
  • Yeah, it's plain DB access, nothing fancy. Still, it would be good to have unit tests, because: 1. It's good to demonstrate that it works 2. Other members of the team can then look at it and see how to use the DAL. – Venemo Sep 18 '11 at 13:51