Preface: test Is an integral part of a good App.Each App is a small set of features.And these small functions are a function or a function algorithm Grouped together.Unit testing is about testing these small functions or functions, and good unit testing can make your code much more robust.XCTest is a framework provided by XCode that provides testing at all levels.
XCTestCase
Each XCode project that creates iOS has a grouping called "Project Name Tests", which is a subclass of XCTestCase, where the test classes are inherited from XCTestCase.(
For example, if you create a new project named Demo, you will see the picture
See what this auto-created file contains
#import <UIKit/UIKit.h>
#import <XCTest/XCTest.h>
@interface DemoTests : XCTestCase
@end
@implementation DemoTests
- (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.
}];
}
@end
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
Naming test cases
All test cases in XCTest are named beginning with test.For example, the above
- (void)testExample {
// This is an example of a functional test case.
XCTAssert(YES, @"Pass");
}
- 1
- 2
- 3
- 4
- 5
- 1
- 2
- 3
- 4
- 5
setUp and tearDown
Setup is a function that runs before all test cases are run and does some common initialization work in this test case
tearDown is executed after all test cases have been executed
Test Case Navigation for XCode
The navigation of test cases is shown in the diagram. In the navigation of test cases, we can run a set of test cases or a single test case.
You can right-click to create a new set of test cases.(
You can also add failure breakpoints for test cases to facilitate debugging.
View test results
Test results can be viewed from the test navigation bar
More detailed test results can be seen from the Report Navigation Bar
Click the arrow behind the test case to jump to the code of the test case.
Common method testing
For example, a new class named Model has this method to generate random numbers within 10.
-(NSInteger)randomLessThanTen{
return arc4random()%10;
}
- 1
- 2
- 3
- 1
- 2
- 3
Thus, the test method is
-(void)testModelFunc_randomLessThanTen{
Model * model = [[Model alloc] init];
NSInteger num = [model randomLessThanTen];
XCTAssert(num<10,@"num should less than 10");
}
- 1
- 2
- 3
- 4
- 5
- 1
- 2
- 3
- 4
- 5
We run this test case individually by clicking on the icon on the left side of the diagram, or in the navigation bar I mentioned above.(
You will then see the output indicating that the test case passed
Test Suite 'Selected tests' started at 2015-06-28 05:24:56 +0000
Test Suite 'DemoTests.xctest' started at 2015-06-28 05:24:56 +0000
Test Suite 'DemoTests' started at 2015-06-28 05:24:56 +0000
Test Case '-[DemoTests testModelFunc_randomLessThanTen]' started.
Test Case '-[DemoTests testModelFunc_randomLessThanTen]' passed (0.000 seconds).
Test Suite 'DemoTests' passed at 2015-06-28 05:24:56 +0000.
Executed 1 test, with 0 failures (0 unexpected) in 0.000 (0.001) seconds
Test Suite 'DemoTests.xctest' passed at 2015-06-28 05:24:56 +0000.
Executed 1 test, with 0 failures (0 unexpected) in 0.000 (0.001) seconds
Test Suite 'Selected tests' passed at 2015-06-28 05:24:56 +0000.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
Common Assertions
How do you determine whether a test case succeeds or fails?XCTest is implemented using assertions.(
The most basic assertion
Indicates that if the expression is satisfied, the test passes, otherwise the corresponding format error occurs.
XCTAssert(expression, format...)
- 1
- 1
There is also an assertion for direct Fail
XCTFail(format...)
- 1
- 1
Other common assertions:
XCTAssertTrue(expression, format...)
XCTAssertFalse(expression, format...)
XCTAssertEqual(expression1, expression2, format...)
XCTAssertNotEqual(expression1, expression2, format...)
XCTAssertEqualWithAccuracy(expression1, expression2, accuracy, format...)
XCTAssertNotEqualWithAccuracy(expression1, expression2, accuracy, format...)
XCTAssertNil(expression, format...)
XCTAssertNotNil(expression, format...)
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
performance testing
The so-called performance test mainly evaluates the running time of a piece of code. The XCTest performance test uses the following formats
For performance tests, each test case runs 10 times at a time.
- (void)testPerformanceExample {
// This is an example of a performance test case.
[self measureBlock:^{
// Put the code you want to measure the time of here.
}];
}
- 1
- 2
- 3
- 4
- 5
- 6
- 1
- 2
- 3
- 4
- 5
- 6
For example, I want to evaluate a piece of code and print NSLog 10,000 times in a loop.(
This is the code that I put in the category of UIImage.
- (void)testPerformanceExample {
// This is an example of a performance test case.
[self measureBlock:^{
for (NSInteger index = 0; index < 10000; index ++) {
NSLog(@"%ld",index);
}
// Put the code you want to measure the time of here.
}];
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
As we all know, testing either succeeds or fails, which introduces a critical issue
- When testing performance, how do you decide whether a performance test case succeeds or fails?
Let's start by running this test case only once, as described above.Then look at the results and output (this test case runs very slowly, don't worry)
Test Case '-[ModelTests testPerformanceExample]' failed (37.432 seconds).
Test Suite 'ModelTests' failed at 2017-02-19 09:57:26.210.
Executed 1 test, with 1 failure (0 unexpected) in 37.432 (37.433) seconds
Test Suite 'ToDoTests.xctest' failed at 2017-02-19 09:57:26.211.
Executed 1 test, with 1 failure (0 unexpected) in 37.432 (37.434) seconds
Test Suite 'Selected tests' failed at 2017-02-19 09:57:26.211.
Executed 1 test, with 1 failure (0 unexpected) in 37.432 (37.437) seconds
Test session log:
/Users/hl/Library/Developer/Xcode/DerivedData/ToDo-bbcdkwvzbmyznocgystdcavfakca/Logs/Test/98E0FA82-BACC-4361-AF39-E0734F73A545/Session-ToDoTests-2017-02-19_095641-jm2eKF.log
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
Then you will find that the test fails!This is because we have not given performance testing a reference time.(
Let's click on the second cross arrow in the picture
Then you see the picture
Let's see what these parameters mean:
- Baseline calculates reference values for standard deviations
- MAX STDD Maximum Allowable Standard Deviation
- Bottom click 1,2...10 You can see the results of each run.
Click Edit, we click Accept on the right side of Average to set the average value for this run to baseline, and then change the MAX STDD to 40%.Run this test case again and you will find that the test is successful.
Asynchronous Test
The logic of an asynchronous test is as follows: First, define one or more XCTestExpectation s to represent the desired results of an asynchronous test.Then set timeout to indicate the maximum time an asynchronous test can execute.Finally, at the end of the asynchronous code completion, fullfill is called to notify the asynchronous test that the condition is met.
- (void)testAsyncFunction{
XCTestExpectation * expectation = [self expectationWithDescription:@"Just a demo expectation,should pass"];
//Async function when finished call [expectation fullfill]
[self waitForExpectationsWithTimeout:10 handler:^(NSError *error) {
//Do something when time out
}];
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 1
- 2
- 3
- 4
- 5
- 6
- 7
Give an example
- (void)testAsyncFunction{
XCTestExpectation * expectation = [self expectationWithDescription:@"Just a demo expectation,should pass"];
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
sleep(1);
NSLog(@"Async test");
XCTAssert(YES,"should pass");
[expectation fulfill];
});
[self waitForExpectationsWithTimeout:10 handler:^(NSError *error) {
//Do something when time out
}];
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
test result
Test Suite 'Selected tests' started at 2015-06-28 05:49:43 +0000
Test Suite 'DemoTests.xctest' started at 2015-06-28 05:49:43 +0000
Test Suite 'DemoTests' started at 2015-06-28 05:49:43 +0000
Test Case '-[DemoTests testAsyncFunction]' started.
2015-06-28 13:49:44.920 Demo[2157:145428] Async test
Test Case '-[DemoTests testAsyncFunction]' passed (1.006 seconds).
Test Suite 'DemoTests' passed at 2015-06-28 05:49:44 +0000.
Executed 1 test, with 0 failures (0 unexpected) in 1.006 (1.007) seconds
Test Suite 'DemoTests.xctest' passed at 2015-06-28 05:49:44 +0000.
Executed 1 test, with 0 failures (0 unexpected) in 1.006 (1.009) seconds
Test Suite 'Selected tests' passed at 2015-06-28 05:49:44 +0000.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
Code Coverage
Select Target, select the Test module, and check Gather coverage data
Then, in the report module, you can see the code coverage for each.m file.
Follow-up:
Update: 2017.02.19 adds code coverage and provides a detailed explanation of performance testing.
Planning for the next article will explain Mock testing and some commonly used Mock gadgets.