Exception handling in FitNesse

Question

This is a FitNesse beginner's question, so bare with me. Gojko Adzic, in his book Test Driven .NET Development with FitNesse, gives some basic tips on reducing the test code. There's a method called LogIn which, based on the username and password, returns player's id or throws an exception when there's no such registered player. Here's the initial version of the test code:

public class CheckLogIn : fit.ColumnFixture
{
    public string username;
    public string password;

    public int LoggedInAsPlayerId()
    {
        try
        {
            SetUpTestEnvironment.playerManager.LogIn(username, password);
            return true;
        }
        catch (Exception)
        {
            return false;
        }
    }
}

This is then replaced with a shorter version:

public class CheckLogIn : fit.ColumnFixture
{
    public string username;
    public string password;

    public int LoggedInAsPlayerId()
    {
        return SetUpTestEnvironment.playerManager.LogIn(username, password);
    }
}

Now the second test has an added bonus of verifying if a correct id is returned, but it doesn't allow you to check if the system rejects an unknown user/wrong password. Is there any special value which can be used in a column to indicate an exception? Or do I have to combine both tests to cover all scenarios? I remember, albeit vaguely at this very moment, there was some kind of unit test pattern for handling exceptions, but I'm sure somebody has already asked about it, so I don't want to duplicate. Unless the community is OK with that, then please suggest a best practice for testing such methods.

In case I'm not being clear:

Say I got one registered player: john.doe/test123/101 (username/password/id). Two of the combinations I would want to test the system against are john.doe/test123/101 and john.doe/johnny/<WrongUserOrPasswordException>

Answer 1

There are two fixture keywords which allow checking for exceptions:

• error - when an exception should be thrown during the test
• exception - to check for a particular exception

This was actually well explained on the following page of the book... My bad for not noticing it straight away. Maybe somebody will find this information useful, so I'm not deleting the question.