Test

Unit Testing Overview
The Xcode unit-testing environment is based on the open-source SenTestingKit framework. Xcode offers two type of unit tests:
 * **Logic tests:** These tests check the correct functionality of a unit of code by itself (not in an app). With logic tests you can put together specific test cases to exercise a unit of code. You can also use them to perform stress-testing of your code to ensure that it behaves correctly in extreme situations that are unlikely in a running app. These tests help you produce robust code that works correctly when used in ways that you did not anticipate.
 * **Application tests:** These tests check units of code in the context of your app. Use them to ensure that the connections of your user-interface controls (outlets and actions) remain in place, ant that your coltrols and controller objects work correctly with your object model as you work on your app. You can also use these tests to perform hardware testing.

Writing Test Case Methods
You add test cases to a test suite by adding test case methods to a test suite class. A test case method is an instance method of a test suite class that's named test..., with no parameters, and whose return type is void. A test case method calls the code being tested (known as the //unit//), and reports whether the calls produced the expected result. Test case methods use a set of macros to check for the expected conditions and report their findings. See.

This is the structure of a test case method:

When Xcode runs unit tests, it invokes each test case method independently. Therefore, each method must prepare and clean up any auxiliary variables, structures, and objects it needs to interact with the subject API. Conveniently, you can add a pair of methods to a test suite class that are called before and after each test case method is invoked: setUp and tearDown:

When there's a reported failure in a setUp or tearDown call, Xcode reports the failure in the test case method that originated the call.

Writing Testable Code
The level of stability you achieve through unit-testing is highly dependent on the quality of the test cases you write. Follow these guidelines as you write code, to ensure that it's easily testable:
 * **Define API requirements:** You should define requirements and outcomes for each method or function that you add to your project. These requirements should include input and output ranges, exceptions thrown and the conditions under which they are raised, and the type of values returned (especially if the values are instances of classes). Specifying requirements and making sure that requirements are met in your code help you write robust, secure code.
 * **Write test cases as you write code:** As you design and write each method or function, write one or more test cases that ensure that the API's requirements are met. It's harder to write unit tests for existing code than for code you are writing.
 * **Check boundary conditions:** If a parameter of a method must have values in a specific range, your tests should pass values that include the lowest and highest values of the range. For example, if a procedure has an integer parameter can have values between 0 and 100, inclusive, the test code for that method should pass the values 0, 50, and 100 for the parameter.
 * **Use negative tests:** Negative tests ensure that your code responds to error conditions appropriately. Verify that your code behaves correctly when it receives invalid or unexpected input values. Also verify that it returns error codes or raises exceptions when it should. For example, if an integer parameter must have values in the range 0 to 100, inclusive, you should create test cases that pass the values -1 and 101 to ensure that the procedure raises an exception or returns an error code.
 * **Write comprehensive test cases:** Comprehensive tests combine different code modules to implement some of the more complex behavior of your API. While simple, isolated tests provide value, stacked tests exercise complex behaviors arnd tend to catch many more problems. These kinds of tests mimic the behavoir of your code under more realistic conditions. For example, in addition to adding objects to an array, you could create the array, add several objects to it, remove a few of them using different methods, and then ensure that the set and number of remaining objects is correct.
 * **Cover your bug fixes with test cases:** Whenever you fix a bug, write one or more tests cases that verify the fix.

Unit-Test Result Macro Reference
The SenTestingKit framework defines a set of test case result macros that report test case results to the framework. When a test fails, the framework sends a test -failure messages, which Xcode displays in the log and issue navigators.

The following sections describe the test result macros you can use in your test case methods. These macros are declared in SenTestCase.h.

When the APIs your test cases evaluate throw exceptions, the test cases produce unknown errors. To test whether your code raises exceptions, create test cases that explicitly check for the presence or absence of exceptions. See.

STFail
Fails the test case.

StFail(failure_description, ...)

Parameters

 * failure_description: Format string specifying error message. Can be nil.
 * ...: (Optional) A comma-separated list of arguments to substitute into failure_description.

STAssertEqualObjects
Fails the test case when two objects are different.

STAssertEqualObjects(object_1, object_2, failure_description, ...)

Parameters

 * object_1: An Object.
 * object_2: An object.
 * failure_desctiption: Format string specifying error message. Can be nil.
 * ...: (Optional) A comma-separated list of arguments to substitute into failure_desctiption.

Detail
The test fails when [object_1 isEqualTo:object_2] is false.

STAssertEquals
Fails the test case when two values are different.

STAssertEquals(value_1, value_2, failure_desctiption, ...)

Parameters

 * value_1: A scalar, structure, or union.
 * value_2: A scalar, structure, or union.
 * failure_desctiption: Format string specifying error message. Can be nil.
 * ...: (Optional) A comma-separated list of arguments to substitute into failure_desctiption.

Detail
The test fails when value_1 is not equal to value_2.

STAssertEqualsWithAccuracy
Fails the test case when the difference between two values is greater than a given value.

STAssertEqualsWithAccuracy(value_1, value_2, accuracy, failure_description, ...)

Parameters

 * value_1: An integer or a floating-point value.
 * value_2: An integer or a floating-point value.
 * accuracy: An integer or a floating-point value.
 * failure_desctiption: Format string specifying error message. Can be nil.
 * ...: (Optional) A comma-separated list of arguments to substitute into failure_desctiption.

Detail
The test fails when the difference between value_1 and value_2 is greater than accuracy.

STAssertNil
Fails the test case when a given expression is not nil.

STAssertNil(expression, failure_desctiption, ...)

Parameters

 * expression: Expression to test.
 * failure_desctiption: Format string specifying error message. Can be nil.
 * ...: (Optional) A comma-separated list of arguments to substitute into failure_desctiption.

STAssertNotNil
Fails the test case when a given expression is nil.

STAssertNotNil(expression, failure_description, ...)

Parameters

 * expression: Expression to test.
 * failure_desctiption: Format string specifying error message. Can be nil.
 * ...: (Optional) A comma-separated list of arguments to substitute into failure_desctiption.

STAssertTrue
Fails the test case when a given expression is false.

STAssertTrue(expression, failure_description, ...)

Parameters

 * expression: Expression to test.
 * failure_desctiption: Format string specifying error message. Can be nil.
 * ...: (Optional) A comma-separated list of arguments to substitute into failure_desctiption.

STAssertFalse
Fails the test case when a given expression is true.

STAssertFalse(expression, failure_description, ...)

Parameters

 * expression: Expression to test.
 * failure_desctiption: Format string specifying error message. Can be nil.
 * ...: (Optional) A comma-separated list of arguments to substitute into failure_desctiption.

STAssertThrows
Fails the test case when an expression doesn't raise an exception.

STAssertThrows(expression, failure_description, ...)

Parameters

 * expression: Expression to test.
 * failure_desctiption: Format string specifying error message. Can be nil.
 * ...: (Optional) A comma-separated list of arguments to substitute into failure_desctiption.

STAssertThrowsSpecific
Fails the test case when an expression doesn't raise an exception of a particular class.

STAssertThrowsSpecific(expression, exception_class, failure_description, ...)

Parameters

 * expression: Expression to test.
 * exception_class: An exception class.
 * failure_desctiption: Format string specifying error message. Can be nil.
 * ...: (Optional) A comma-separated list of arguments to substitute into failure_desctiption.

Detail
The test fails when expression doesn't raise an exception of a particular class with a given name.

STAssertThrowsSpecifiedNamed
Fails the test case when an expression doesn't raise an exception of a particular class with a given name.

STAssertThrowSpecificNamed(expression, exception_class, exception_name, failure_description, ...)

Parameters

 * expression: Expression to test.
 * exception_class: An exception class.
 * exception_name: A string with the name of an exception.
 * failure_desctiption: Format string specifying error message. Can be nil.
 * ...: (Optional) A comma-separated list of arguments to substitute into failure_desctiption.

Detail
The test fails when expression doesn't raise an exception of the class exception_class with the name exception_name.

STAssertNoThrow
Fails the test case when an expression raises an exception.

STAssertNoThrow(expression, failure_description, ...)

Parameters

 * expression: Expression to test.
 * failure_desctiption: Format string specifying error message. Can be nil.
 * ...: (Optional) A comma-separated list of arguments to substitute into failure_desctiption.

STAssertNoThrowSpecific
Fails the test case when an expression raises an exception of a particular class.

STAssertNoThrowSpecific(expression, exception_class, failure_description, ...)

Parameters

 * expression: Expression to test.
 * exception_class: An exception class.
 * failure_desctiption: Format string specifying error message. Can be nil.
 * ...: (Optional) A comma-separated list of arguments to substitute into failure_desctiption.

Detail
The test fails when expression raises an exception of the class exception_class.

STAssertNoThrowSpecificNamed
Fails the test case when an expression doesn't raise an exception of a particular class with a given name.

STAssertNoThrowSpecificNamed(expression, exception_class, exception_name, failure_description, ...)

Parameters

 * expression: Expression to test.
 * exception_class: An exception class.
 * exception_name: A string with the name of an exception.
 * failure_desctiption: Format string specifying error message. Can be nil.
 * ...: (Optional) A comma-separated list of arguments to substitute into failure_desctiption.

Detail
The test fails when the expression raises an exception of the class exception_class with the name exception_name.

STAssertTrueNoThrow
Fails the test case when an expression is false or raises an exception.

STAssertTrueNoThrow(expression, failure_description, ...)

Parameters

 * expression: Expression to test.
 * failure_desctiption: Format string specifying error message. Can be nil.
 * ...: (Optional) A comma-separated list of arguments to substitute into failure_desctiption.

STAssertFalseNoThrow
Fails the test case when an expression is true or raised an exception.

STAssertFalseNoThrow(expression, failure_description, ...)

Parameters

 * expression: Expression to test.
 * failure_desctiption: Format string specifying error message. Can be nil.
 * ...: (Optional) A comma-separated list of arguments to substitute into failure_desctiption.