Functional Test Pattern, Exception over Assert

The Idea is that a test should only result in a fail status if the functionality being tested isn't working and if the dependent functionality inst working it should only result in a error status. You can achieve this by raising a exception when the dependent functionality isn't working and Asserting on the functionality being tested.

Code:

// if it's dependent functionality
if(!UserCreated("TestUser"))
    throw new Exception("User wasn't created");
// if it's functionality being tested
Assert.That(UserCreated("TestUser"));

Use Assertion as little as possible in a functional test,

In a test suite for users and roles you might have 2000 test cases, but you might have only 100 test that actually test creating a user and the rest of the tests will test other functionality above and beyond that. Those other tests will have will have pre-steps or setup that will add the users before the actual test.

• Create user (dependent functionality)
• Check property 
• Login as user (dependent functionality)
• Check that user is logged in
• Change user name (functionality being tested)
• Check new user name

Code:

[Test]
public void ChangeUserName()
{
    User responseUser = CreateUser("Rick");
    if(responseUser.Name != "Rick")
        throw new Exception("User has incorrect name");
    if(!LoginAs("Rick"))
        throw new Exception("Login failed as user");
    Assert.That(ChangeUserName("Rick Casady"));
}

Now when you get an NUnit test report and the create user functionality is broken your report will say 1999 tests errored and 1 test failed. If you gave your tests meaningful names you'll know exactly what broke. Your test name might be AddAUserWithDefultPermissions()

Exceptions should also be raised in any helper classes any time there is a test run that has no failures and has errors you'll know you need to write at least one new test.