views:

69

answers:

5
public Category GetByName(string name)
        {
            Category category = Session.CreateCriteria(typeof (Category))
                .Add(Expression.Eq("Name", name))
                .UniqueResult<Category>();


            return category;
        }

Or is it so clear that it doesn't need testing?

+1  A: 

What do you want to test? NHibernate?

Mariano
A: 

It's pretty clear as is, although what happens if you have more than one category with the same name? If that is not possible due to your architecture (uniqueness is enforced elsewhere) it would be worth a comment to indicate that fact.

BryanD
+5  A: 

I think there are a few tests that might need to be written:

  1. Test that you get a Category that matches the name specified from a pool of named Categories.
  2. Test that you get one Category from a pool of Categories with the same name.
  3. Test that you get null when using a name that does not exist in a pool of Categories.

As for it being philosophically clear enough not to require testing; I believe that to be a matter of opinion. If you've written that line 3 million times and are confident that it works as expected, you might not find it worth your time. However if it's new terrain, it's always worth spending the extra moment to ensure it's working as expected.

ddc0660
+1  A: 

Just because the code is clear doesn't mean it should NOT be unit tested.

The tests are simple, give it a name does it give you the right category back? Is it not NULL?

You also are not writing test for just this method today. What if in the future you refactor how would you know you didn't introduce breaking changes?

David Basarab
A: 

Personally, I wouldn't unit test this. I would write some integration tests instead.

Paco