Database Reference
In-Depth Information
The actual test case itself just calls the method under test with good data, and then
makes sure that we got a good value back, and that the URL string matches what we
expect. All of the unit test assertions are documented, but they generally follow
the pattern of a test condition, an error message that will be used with the
NSString stringWithFormat
message, and the arguments to the formatter. In this case,
we use
STAssertNotNil
and
STAssertEqualObjects
. You should understand that
STAssertEqualObjects
and
STAssertEquals
have different behaviors: the former uses the
equals
message, while the latter tests for literally object equality.
If you run this test as is (by selecting Product
→
Test, typing
⌘
-U, or holding the run
icon and selecting Test), it will fail, as shown in
Figure 5-3
.
Figure 5-3. A failing test run
This is because we're testing the generated URL string against the empty string. So
where do we get a good string to test it against? In pure TDD, we would have figured
out what string we should expect before we wrote the code and the test would have
tested for it. In lazy man's TDD, we can run the test against a known bad string, copy
the good string out of the error log by right-clicking on the error in the navigator and
selecting “copy”, inspect it and make sure that it looks correct, then paste it into the
“expected” string part of the test.
Happy path testing is all well and good, but as you probably know, the world is full of
sad, broken paths. To round out the tests, we can write a number of negative cases,
shown in
Example 5-3
.
Example 5-3. Writing negative test cases
-(void) testGetForecastWebServiceEndpointMissingZip {
@try {
[WebServiceEndpointGenerator
getForecastWebServiceEndpoint:nil
startDate:testStartDate endDate:testEndDate];
} @catch (NSException * e) {
STAssertEqualObjects(@"Missing Argument Exception",
e.name, @"Wrong exception type");
