Using Nunit to test constructor

Question

Hello,

I'm new to Nunit testing and I wanted to test the following constructor:

public class IngredientDAONHibernate : NutritionLibrary.DAO.IngredientDAO

    {

          private Configuration config;
        private ISessionFactory factory;

        public IngredientDAONHibernate()
        {
            try
            {
                config = new Configuration();
                config.AddClass(typeof(NutritionLibrary.Entity.Ingredient));
                config.AddClass(typeof(Entity.Nutrient));
                config.AddClass(typeof(Entity.NutrientIngredient));
                       factory = config.BuildSessionFactory();
            }
            catch (Exception e)
            {

                // logger.Error("Exception Occured", e);
            }
        }

The test stub is as follows:

[TestMethod()]
        public void IngredientDAONHibernateConstructorTest()
        {
            IngredientDAONHibernate target = new IngredientDAONHibernate();

        }

Could someone help me with some tips as to how I can get started? Thanks!

Answer 1

I would suggest that you don't catch all the exceptions, but, if there are certain you want to catch and ignore then just do those, otherwise it is harder to tell if you have a problem.

I tend not to test the constructor, unless it is doing quite a bit, and it will be obvious if there is a problem when doing the other unit tests, as, if the constructor fails you should see by the exception, and by the fact that all the tests will be failing.

If you want to test this constructor, limit your exceptions and just ensure that there is no exception when you run the test.

Answer 2

Let me turn the question back on to you.. How do you know if the constructor executed as intended ?

Normally constructors are trivial.. but here it seems that you have some third party lib interfacing code that you need some confidence with.

If you only want to test that there are no exceptions raised from within the constructor... then Extract a logger interface. Now in your test pass in a mock logger (a fake can also suffice), which should help you to sense if an exception was logged.

[TestMethod()]
        public void IngredientDAONHibernateConstructorTest()
        {
            _errorLogged = false;
            ILogger logger = this; // make test fixture implement the logger interface ; self-shunt
            IngredientDAONHibernate target = new IngredientDAONHibernate(logger);

            Assert.IsNotNull(target);
            Assert.IsFalse(_errorLogged, 
               String.Format("ERROR! Constructor has thrown {0}", _loggedException) );
        }

        bool _errorLogged;
        Exception _loggedException;
        public void Error(string message, Exception e)
        { 
           _errorLogged = true;
           _loggedException = e;
        }

Answer 3

Like everyone else, I would caution against catching Exception. The documentation should tell you what exceptions can be expected and you could write specific Catch clauses for each of them, if that made sense.

Leaving that aside, your tests should verify that your objects are in the state you expect. Given what we can see, all you can do is test that it's not null. If you can force an exception, you could test that the logger gets the exception message. If there was a public property that gave access to your factory, you would want to test that (not null, perhaps other things) and likewise with the config field. For that, if you have access to the added classes, you could test not null and count==3. If the exact objects are important, you could test that they are there. It's always tricky to decide how much to trust third-party stuff. Generally, I do unless I get evidence that I shouldn't.

When it comes to testing methods, test for each parameter whatever is possible. So, for a string, test null and emptystring plus relevant (valid and invalid) values. If you're expecting alphanumerics, test special chars as well. If data has boundaries test values on and either side of the boundary(ies) plus typical values. E.g. if you're expecting an int between 0 and 10, test -1, 0, 1, 5, 9, 10, 11. It only takes seconds to write but it can save you hours in two years when you're trying to fix a bug.