Unit/Integration Tests, how granular should they be?

Question

I am testing the UI of my ASP.Net Web Forms app using NUnit/Watin. I understand the high level concepts around TDD, Unit Testing, integration testing etc, but have not had much of a chance to put them to use until now.

So, when I am testing the validation logic on a data entry form, should I be writing one test that triggers each of my validation errors (i.e. Field x is required), or a separate test for each of the validation errors that should be thrown by the form. Is this simply a style issue, or are there valid reasons for writing several tests instead of one that hits on all possible combos of my validation logic?

Psuedo code:

    [Test]
    public void Validation()
    {
       //Do some stuff to test that username is required.
       Assert.AreEqual(true, ie.ContainsText("Username is required.");

       //Do some stuff to test that passwword is required.
       Assert.AreEqual(true, ie.ContainsText("Password is required.");
    }

vs.

[Test]
public void ValidateUserName()
{
   //Do some stuff to test that username is required.
   Assert.AreEqual(true, ie.ContainsText("Username is required.");
}

[Test]
public void ValidatePassword()
{
   //Do some stuff to test that passwword is required.
   Assert.AreEqual(true, ie.ContainsText("Password is required.");
}

Answer 1

I would lean towards one test per validation:

• If you completely break validation, two tests fail, so you know immediately about everything you've broken. If they're in the same test then the first failure will mask the second until the first is fixed.

• As soon as you break anything you'll get a description of exactly what's broken in the names of the failed methods. Many unit testing GUIs will give you a little red traffic light next to each failing test, and these will naturally highlight and describe all your errors.

Having said that, the important thing is that you test at all - where particular tests appear in a class is a minor detail...