Question

I begin studying Unit testing with “(NUnit)”. I know that this type of testing is used to test “classes” , “functions” and the “interaction between those functions”.

In my case I develop “asp.net web applications”.

• How can i use this testing to test my
  pages(as it is considered as a class
  and the methods used in)and in which sequence?, i have three layers:

  1. Interface layer(the .cs of each page).

  2. Data access layer(class for each entity)(DAL).

  3. Database layer (which contains connection to the database,open connection,close connection,….etc).

  4. Business layer(sometimes to make calculation or some separate logic).

• How to test the methods that make connection to the database?

• How to make sure that my testing not a waste of time?.

Answer 1

There are unit and integration tests. Unit testing is testing single components/classes/methods/functions and interaction between them but with only one real object (system under test-SUT) and test doubles. Test doubles can be divided to stubs and mocks. Stubs provide prepared test data to SUT. That way you isolate SUT from the environment. So You don’t have to hit database, web or wcf services and so on and you have same input data every time. Mocks are used to verify that SUT works as expected. SUT calls methods on mock object not even knowing it is not real object. Then You verify that SUT works by asserting on mock object. You can write stubs and mocks by hand or use one of many mocking frameworks. One of which is http://code.google.com/p/moq/

If You want to test interaction w/database that’s integration testing and generally is a lot harder. For integration testing You have to setup external resources in well known state.

Let’s take your layers:

1. You won’t be able to unit test it. Page is to tightly coupled to ASP.NET runtime. You should try to not have much code in code behind. Just call some objects from your code behind and test those objects. You can look at MVC design patters. If You must test Your page You should look at http://watin.org/. It automates Your internet browser, clicks buttons on page and verifies that page displays expected result’s.

2. This is integration testing. You put data in database, then read it back and compare results. After test or before test You have to bring test database to well known state so that tests are repeatable. My advice is to setup database before test runs rather then after test runs. That way You will be able to check what’s in database after test fails.

3. I don’t really know how that differs from that in point no. 2.

4. And this is unit testing. Create object in test, call it’s methods and verify results.

How to test methods that make connections to the database is addresed in point 2.
How to not waste time? That will come with experience. I don’t have general advice other then don’t test properties that don’t have any logic in it.

For great info about unit testing look here:

http://artofunittesting.com/

http://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530

http://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627/ref=sr_1_2?ie=UTF8&s=books&qid=1306787051&sr=1-2

http://www.amazon.com/xUnit-Test-Patterns-Refactoring-Code/dp/0131495054/ref=sr_1_1?ie=UTF8&s=books&qid=1306787051&sr=1-1

Edit:

SUT, CUT – System or Class under test. That’s what You test.
Test doubles – comes from stunt doubles. They do dangerous scenes in movies so that real actors don’t have to. Same here. Test doubles replace real objects in tests so that You can isolate SUT/CUT in tests from environment.

Let’s look at this class

public class NotTestableParty
{
    public bool ShouldStartPreparing()
    {
        if (DateTime.Now.Date == new DateTime(2011, 12, 31))
        {
            Console.WriteLine("Prepare for party!");
            return true;
        }
        Console.WriteLine("Party is not today");
        return false;
    }
}

How will You test that this class does what it should on New Years Eve? You have to do it on New Years Eve 🙂

Now look at modified Party class
Example of stub:

    public class Party
    {
        private IClock clock;

        public Party(IClock clock)
        {
            this.clock = clock;
        }

        public bool ShouldStartPreparing()
        {
            if (clock.IsNewYearsEve())
            {
                Console.WriteLine("Prepare for party!");
                return true;
            }
            Console.WriteLine("Party is not today");
            return false;
        }
    }

    public interface IClock
    {
        bool IsNewYearsEve();
    }

    public class AlwaysNewYearsEveClock : IClock
    {
        public bool IsNewYearsEve()
        {
            return true;
        }
    }

Now in test You can pass the fake clock to Party class

        var party = new Party(new AlwaysNewYearsEveClock());
        Assert.That(party.ShouldStartPreparing(), Is.True);

And now You know if Your Party class works on New Years Eve. AlwaysNewYearsEveClock is a stub.

Now look at this class:

    public class UntestableCalculator
    {
        private Logger log = new Logger();

        public decimal Divide(decimal x, decimal y)
        {
            if (y == 0m)
            {
                log.Log("Don't divide by 0");
            }

            return x / y;
        }
    }

    public class Logger
    {
        public void Log(string message)
        {
            // .. do some logging
        }
    }

How will You test that Your class logs message. Depending on where You log it You have to check the file or database or some other place. That wouldn’t be unit test but integration test. In order to unit test You do this.

    public class TestableCalculator
    {
        private ILogger log;
        public TestableCalculator(ILogger logger)
        {
            log = logger;
        }
        public decimal Divide(decimal x, decimal y)
        {
            if (y == 0m)
            {
                log.Log("Don't divide by 0");
            }
            return x / y;
        }
    }

    public interface ILogger
    {
        void Log(string message);
    }
    public class FakeLogger : ILogger
    {
        public string LastLoggedMessage;
        public void Log(string message)
        {
            LastLoggedMessage = message;
        }
    }

And in test You can

var logger = new FakeLogger();
        var calculator = new TestableCalculator(logger);
        try
        {
            calculator.Divide(10, 0);
        }
        catch (DivideByZeroException ex)
        {
            Assert.That(logger.LastLoggedMessage, Is.EqualTo("Don't divide by 0"));
        }

Here You assert on fake logger. Fake logger is mock object.