Checking for errors
Prev Chapter 5. Writing simple test scripts Next

Checking for errors

A business analyst comes in with two new requests:

  • Can we verify that a player cannot log in with a wrong password?

  • Can we verify that a player will not be able to register if the username is already taken?

The .NET FIT runner has a non-standard extension that allows us to check exceptions and errors. Just write error in the cell to signal that an exception should be thrown during the test.

We can even check for a particular exception message or code. In order to do that, we use a different keyword, exception. The syntax is exception[ExceptionType], exception["Exception Message"] (note the quotes) or exception[ExceptionType:"Exception Message"].

Figure 5.2. Registration tests - second attempt

Registration tests - second attempt

Fixture keywords

In addition to exception, there are a few other fixture keywords you should know:

fail[]

Expects that a comparison will fail - put the expected value in the square brackets. For example, fail[3] will pass if the actual result is not 3.

null

Equal to .NET null. Can be used both as input and for a value check.

blank

Equal to a .NET empty string. Can be used both as input and for a value check.

Note that leaving the cell empty does not automatically check that the result is either null or an empty string. An empty cell makes FitNesse print out the actual result without comparing it to anything, and is a useful trick when you just want to see the result of a method (see Use blank cells to print out results).

Programmers would typically like to check for an exact exception type or message, but this makes tables less readable for business analysts and customers. My advice is to use the level of detail appropriate for the type of test. In customer-oriented tests, error keyword might be quite sufficient. In internal functional tests, full type and message checks provide the greatest level of regression-test safety. A compromise is to use just the exception keyword and a human-understandable[17] message.

Figure 5.3. Registration tests - checking for errors

Registration tests - checking for errors

Note that in Figure 5.3, “Registration tests - checking for errors” we have just joined the data rows for two registrations and two login checks. There is no need to repeat the table header each time.


[17] Yes, programmers are humans too, but I mean understandable by an average English-speaking human, not someone who has nightmares in C#.

Prev Up Next
Using symbols to check dynamic values Home Playtime