Chapter 7. What happens between two Unit Tests?

[simons1994]

I am interested about why does persistent store of type NSInMemoryStoreType clear out between two small tests in one test class. Why? App even don’t reloads. It seems to be something happens between test and very likely making coreDataStack = nil in tearDown section do not play crucial role.

[shogunkaramazov]

@astralbodies Can you please help with this when you get a chance? Thank you - much appreciated! :]

[simons1994]

Guys whats going on? Please respond to my question. Why do you ignore my question?

[jrturton]

Hi,

As it says in the chapter:

Using the in-memory store and creating a new context in setUp accomplishes this reset for you.

When you say:

very likely making coreDataStack = nil in tearDown section do not play crucial role.

You’re completely wrong. An in-memory story only exists in memory, and only for as long as the persistent store coordinator that owns it lives. When you set the core data stack to nil and re-create it, you get a brand new persistent store coordinator and a brand new in-memory store, with no data. That’s the entire point of using the in-memory store for unit tests, as discussed in the “Core Data Stack for Testing” part of the chapter.

[simons1994]

Really? Sounds good, but then how can you explain this “phenomenon” derived from your book’s attached files:

 class CampSiteServiceTests: XCTestCase {
// MARK: Properties
var campSiteService: CampSiteService!
var coreDataStack: CoreDataStack!

override func setUp() {
    super.setUp()
    // Put setup code here. This method is called before the invocation of each test method in the class.
    coreDataStack = TestCoreDataStack()
    campSiteService = CampSiteService(managedObjectContext: coreDataStack.mainContext, coreDataStack: coreDataStack)
    
}
    (1)     func testGetCampSiteWithMatchingSiteNumber() {
   _ = campSiteService.addCampSite(1, electricity: true, water: true)
    
    let campSite = campSiteService.getCampSite(1)
    XCTAssertNotNil(campSite, "A camp site should be returned")
}
  (2)  func testGetCampSiteNoMatchingSiteNumber() {
  //  _ = campSiteService.addCampSite(1, electricity: true, water: true)
    let campSite = campSiteService.getCampSite(1)
    XCTAssertNil(campSite, "No campsite should be returned")
}
 
override func tearDown() {
    // Put teardown code here. This method is called after the invocation of each test method in the class.
    super.tearDown()
 ---------------> //    campSiteService  = nil
 --------------->    //    coreDataStack = nil


}
  }

According to you " When you -------------->set the core data stack to nil<-------- and re-create it, you get a brand new persistent store coordinator and a brand new in-memory store, with no data. That’s the entire point of using the in-memory store for unit tests, as discussed in the “Core Data Stack for Testing” part of the chapter." As you can notice in (1) you added a camp to store (campSiteService.addCampSite(1, electricity: true, water: true)) , then i did not set coreDataStack = nil , according to ( -------------->set the core data stack to nil<-------- ) my (2) should fail, but it passes, then maybe setting coreDataStack did not play completely crucial role? (test says it for themselves) , maybe nevertheless redefenition of coreDataStack comes into play in setUp() section?

[jrturton]

Setting the value to nil in tearDown leaves everything the way it was before any tests are run. Creating a new value in setUp would replace anything that already existed in that variable, which yes, is effectively setting it to nil and re-creating it for the next test.

You could therefore argue that the code in tearDown is not necessary, but when writing tests you shouldn’t assume that another test will be run straight after, or that the set up of the next test will automatically reset everything for you.

So perhaps I didn’t quite understand your original question, you were asking why we bother setting the stack to nil in tearDown when you don’t really need to because you’re making another one straight after in the set up method for the next test. The reason we do it is to demonstrate good practice - make things in setUp, destroy them in tearDown. When a test is run, for it to be truly isolated, everything should be the same as it was before the test was run. If you put off destroying variables until set up of the next test, you’re not abiding by that principle, and for other, more complex tests, you could be setting yourself up for nasty, hard-to-find bugs.