Database Reference
In-Depth Information
Both tests use the
addCampSite
method to create a new
CampSite
. You know this
method works from your previous test, so there's no need to test it again. The
actual tests cover retrieving the
CampSite
by ID and verifying that it is or isn't
nil
.
Think about how this test is much more reliable starting from an empty database
for every test. If you weren't using the in-memory store, there could easily be a
campsite matching the ID for the second test, which would then fail!
Run the unit tests. The test expecting a
CampSite
fails because you haven't
implemented
getCampSite
yet.
Notice the other unit test expecting no site passes. This is an example of a false
positive, because the method always returns
nil
. It's important that you add tests
for multiple scenarios for each method to exercise as many code paths as possible.
Implement
getCampSite
in
CampSiteService.swift
with the following code:
public
func
getCampSite(siteNumber:
NSNumber
) ->
CampSite
? {
let
fetchRequest =
NSFetchRequest
(entityName:
"CampSite"
)
fetchRequest.
predicate
=
NSPredicate
(
format:
"siteNumber == %@"
, argumentArray: [siteNumber])
var
error:
NSError
?
let
results =
self
.
managedObjectContext
.
executeFetchRequest
(
fetchRequest, error: &error)
if
error !=
nil
|| results ==
nil
{
return
nil
}
return
results!.
first
as
CampSite
?
}
Now re-run the unit tests and you should see green check marks. Ah, the sweet
satisfaction of success.
