0

I have created a test project and noticed that XCode generates some test class named: YourProjectName-ProjectTests

This is how it looks like:

- (void)setUp {
    [super setUp];
    // Put setup code here. This method is called before the invocation of each test method in the class.
}

- (void)tearDown {
    // Put teardown code here. This method is called after the invocation of each test method in the class.
    [super tearDown];
}

- (void)testExample {
    // This is an example of a functional test case.
    XCTAssert(YES, @"Pass");
}

- (void)testPerformanceExample {
    // This is an example of a performance test case.
    [self measureBlock:^{
        // Put the code you want to measure the time of here.
    }];
}

Would anyone be able to explain me how to use these automated testing methods? Is there an official documentation on this?

Are those test meant to be used as UI testing or as app code testing? Or both?

mm24
  • 9,280
  • 12
  • 75
  • 170
  • Link to Apple documentation (via an internet search: https://developer.apple.com/library/ios/documentation/DeveloperTools/Conceptual/testing_with_xcode/Introduction/Introduction.html#//apple_ref/doc/uid/TP40014132-CH1-SW1 . There was also a video from WWDC 2014: `#414 Testing in Xcode 6` (link: https://developer.apple.com/videos/wwdc/2014/) and I think there was also a WWDC 2013 video. – Robotic Cat Feb 11 '15 at 00:54
  • Check out [UI Testing in Xcode 7](http://masilotti.com/ui-testing-xcode-7) with details on how to write tests and use the framework. – Joe Masilotti Jun 29 '15 at 15:01

2 Answers2

1

This is how Unit Testing is implemented in Xcode.

The setUp and TearDown methods are to prepare any mock data necessary to test a unit (which is select part of code).

The two test methods there are just an example. Usually as an author of the unit of code, you know well what the unit supposed to do and what it should not.

Using test methods you test how the assumptions and expectations are satisfied by the unit. The convention is to have a separate test method for each assumption/expectation of a behaviour of the unit.

For example given class that handles strings that has a method to to make all strings CAPS, you would test that passing any random nonCaps string would still return ALL CAPS. An putting none truing as a parameter would return nil or error.

So basically you test your units to behave as expected.

There's a whole theory behind Unit Testing which is out of scope of this thread. Just Google it.

Earl Grey
  • 7,426
  • 6
  • 39
  • 59
1

You an perform UI tests through XCTest but it's designed for unit testing. Instruments has UI Automation which is designed for UI testing.

Opening up XCTestAssertions.h will give you a pretty good reference for what's included in XCTest. Generally all the assertions follow a similar pattern:

XCTAssertSomething(somethingBeingTested, @"A message to display if the test fails");

Hitting ⌘ 5 will bring up the test navigator which lets you run all of your tests, all of your failed tests, or individual tests. You can also run a test by clicking on the diamond shape to the left of the method name in the editor.

Here are a few tips I've come across when unit testing with XCTest:

  • The last argument in assertions is optional but in some cases it's useful to describe the behaviour you're looking for.

  • Tests are not run in any specific order, but your tests shouldn't rely on each other anyway.

  • Mock objects let you test far, far more than basic assertions. I like OCMock.

  • You can use instruments on your tests for debugging.

Finally, if you have access to another machine you can set up OSX Server to automatically run your tests daily or on every commit and notify you if any of the tests fail.

Community
  • 1
  • 1
psobko
  • 1,548
  • 1
  • 14
  • 24