4

I'd like to think that I understand the idea of inheritance but apparently I don't because I'm confused as to why there a setup method in XCTestCase if XCTest provides the setup method in its class? XCTestCase is a subclass of XCTest but after reading the Apple docs, it doesn't look any different between the two.

import XCTest
@testable import FirstDemo

class FirstDemoTests: XCTestCase {

    override func setUp() {
        super.setUp()
        // Put setup code here. This method is called before the invocation of each test method in the class.
    }

    override func tearDown() {
        // Put teardown code here. This method is called after the invocation of each test method in the class.
        super.tearDown()
    }

    func testExample() {
        // This is an example of a functional test case.
        // Use XCTAssert and related functions to verify your tests produce the correct results.
    }

    func testPerformanceExample() {
        // This is an example of a performance test case.
        self.measure {
            // Put the code you want to measure the time of here.
        }
    }

}
Laurence Wingo
  • 3,912
  • 7
  • 33
  • 61
  • Which setup method are you talking about? The one inherited from `XCTest` that you are overriding in your snippet or the class method inherited from `XCTestCase`? – dan Mar 29 '17 at 21:51
  • @dan the one I'm overriding in my snippet – Laurence Wingo Mar 30 '17 at 01:43
  • @dan when I look at Apple's references, they both (XCTest and XCTestCase) have these methods but they look similar or at least I'm not able to see Apple's implementation – Laurence Wingo Mar 30 '17 at 01:44

2 Answers2

7

XCTest is a base class, with empty setUp() and tearDown() methods.

XCTestCase inherits from XCTest, so it inherits those same methods. It doesn't have its own implementation of them. They're just do-nothing methods, anyway. They're only defined so that we can override them. This is an example of the Template Method design pattern.

Why define these methods in XCTest, or have XCTest at all? The test runner can work with anything that subclasses from XCTest, and knows nothing about XCTestCase. This potentially allows us to define new ways of defining test suites other than XCTestCase subclasses, while still integrating with the XCTest framework.

For more about xUnit architecture, see JUnit: A Cook's Tour

Jon Reid
  • 20,545
  • 2
  • 64
  • 95
2

You can override a method in a subclass to add more functionality to what the superclass has.

You can override the superclass's implementation completely or you can call super.setUp() in the overriding method to execute the superclass's implementation before anything that you add in the override.

In tests, it's common for an XCTestCase subclass to override setUp() to add common setup actions for that class, whereas the superclass's implementation will execute common setup actions for your whole suite. For example, one XCTestCase subclass will have a setUp() method which launches the app, and a subclass of that class will have a setUp() method which calls its superclass setup and then initializes the area under test in that class. In a unit test, this could mean creating an object, or in a UI test, this could mean navigating to a particular page in your app.

You need to override XCTestCase's setUp() when you subclass it if you want something to happen during the setup stage of your tests as it has an empty implementation by default.

The reason that XCTest has a setUp() method defined (even though it does nothing) is to enable other methods on XCTest to call setUp(), for example, invokeTest() on XCTestCase calls setUp(). This enables users of the framework to specify actions to be done at the beginning of each test by overriding the setUp() method, which does not require any test invocation logic, instead of having to override methods with other logic in them, which we wouldn't necessarily know about and may not implement correctly or at all when overriding the method. This model makes setUp() a safe place for you to execute code entirely of your choosing, without needing to worry about whether you have broken the entire test framework.

Oletha
  • 7,324
  • 1
  • 26
  • 46