iOS Test summary

iOS test

Chapter One iOS testing

While writing the business code, you also write and maintain the corresponding test code. Because unit testing can not only ensure the correctness of code operation, but also help to arrange and think of the code structure, which helps to improve itself.

For a continuous integration platform, testing is still very important. The more automated tests you can use in a project, the greater the value of the platform. The greatest benefit of continuous integration is the ability to identify problems early and reduce the cost of solving problems. And the means of finding the problem lies in testing.

For example, the output must be clicked after a series of buttons can be displayed on the screen, we can build a similar scene in the code, and then call in the code we want to check the code, and the results of the operation and our assumptions in the program to compare, if consistent, it means that our code is not a problem , is working as expected.

We make certain conditions and assumptions and use them as conditions to test the code, and compare the expected results to the actual running results, which is the basic way of testing in software development.

The lowest layer of the test is the unit test, that is, the use of Xcode6.0 after the xctest or Kiwi, and then the business logic test, then the system test.

Xcode's instruments is an integral part of building Xcode's continuous integration. Instruments contains a lot of templates, such as leaks,alloction,automation and so on, can dynamically analyze and track memory, CPU and file system.

Chapter II Unit Testing

1. Overview

Unit testing, as one of the components of Agile development practice, aims to improve the efficiency of software development and maintain the health of code. The goal is to prove that the software works correctly, rather than finding bugs (the goal of discovering bugs is positively correlated with development costs, although finding bugs is a means of guaranteeing software quality, which is clearly the opposite of reducing the cost of software development). It is a guarantee of the quality of software, for example, after refactoring we need to ensure the normal operation of software products. Writing unit tests is not a guarantee that unit tests are not guaranteed to reduce the chances of a bug occurring, but because writing unit tests can take some time and effort, and thus inevitably increases the cost.

2. Test Practice

1. Each functional class should provide unit testing, and each test class depends only on the class of test to which it is being tested. Test with forged objects to avoid any impact on other classes.

eg

A test class is guaranteed to focus on only one of the tested classes, and when the test fails, it can quickly locate who has made the error without being disturbed by other classes.

2. The test case (method) name should be self-explanatory and independent.

3. The assertion statement needs to interpret the intent of the tester.

4. Use refactoring to make the method easier to test.

5. Changes require support for new tests.

3. Test Case

1. Asynchronous testing

-(void) testhttprequest{

//create expectations (equivalent to a nsrunloop, because we don't know when asynchronous execution ends)

xctestexpectation *expectation = [self expectationwithdescription:@ "Handler called"];

MyClass = [[MyClass alloc]init];

[MyClass postwithurl:@ "http://baidu.com" callbackresult:^ (nsurlresponse *response, NSData *data, Nserror * Connectionerror) {

//Expection call completed

[expectation fulfill];

xctassertequalobjects (response, @ "bar");

//Determine when logging in to parse the data here, using assertions to determine whether the login is successful

}];

//Run loop in handling events until all expectations are met or timed out

[self waitforexpectationswithtimeout:5 handler:nil];

}

2.XCTest Performance Test

There are measureblock in Xctest: Methods to test the performance of an algorithm or a part, as follows:

-(void) testperformance{

//test code performance of a block (e.g. test algorithm, read memory, etc.)

[Self measureblock:^{

//Set the initial state

[SELF.TESTVC Pressview:[self.testvc.view viewwithtag:1000];

//Iterate for 100000 cycles of adding 2

for (int i=0; i<100000; i++) {

[SELF.TESTVC Pressview:[self.testvc.view viewwithtag:1000];

    }

  }];

}

3. Test application Create an instance of TESTVC

-(void) testappliation{

SELF.TESTVC = (viewcontroller*) [[UIApplication sharedapplication] Delegate].window.rootviewcontroller;

UIView *testview = Self.testVC.view;

//Judging non-null assertions

Xctassertnotnil (TestView, @ "Cannot find Calcview instance");

}

Chapter III Behavior-driven testing (TDD)

1. Overview

The benefits of test-driven development, which are guided by requirements, are tested to guide developers through the design and architecture of software, and write the most refined code to allow test cases to run through. After proper refactoring, test cases and product code can achieve a healthier state.

It is designed to solve specific problems and help developers determine what should be tested. In addition, it encourages developers to figure out what their needs are, and it introduces a common language that helps you easily understand the purpose of testing.

Drive testing is primarily about behavioral testing. An object in a design app. It has an interface that defines its methods and dependencies. These methods and dependencies declare the conventions of the objects. They define how to interact with other parts of the app, and what its capabilities are.

2. Use

1. Configuring the Kiwi Framework

Import Kiwi framework using Cocoapods (Kiwi import to Testtarget) eg:

Target: "Testxcodetesttests",: Exclusive = True do

Platform:ios, ' 7.0 '

Pod ' Kiwi ', ' ~> 2.3.1 '

End

2. Create an empty class that inherits the Xctestcase. Import Kiwi framework after removing all code

3. The specific test uses the following code:

Describe describes the contents of a test object (typically a test file describes only one class)

Describe (@ "simplestring", ^{

Context describes test contexts

Context (@ "when assigned to ' Hello World '", ^{

NSString *greeting = @ "Hello World";

The ontology of IT description testing

It (@ "should exist", ^{

This encapsulates a method similar to assertions in Xctest

[[Greeting Shouldnot] benil];

});

It (@ "should equal to ' Hello world '", ^{

[[Greeting should] equal:@ "Hello World"];

});

});

});

To test the DataSource method of TableView using Kiwi:

Spec_begin (ARRAYDATASOURCESPEC)

Describe (@ "Arraydatasource", ^{

Context (@ "Initializing", ^{

It (@ "should not being allowed using init", ^{

[[[[Arraydatasource alloc] init] should] benil];

});

});

Context (@ "Configuration", ^{

__block Detialtableviewcell *configuredcell = nil;

__block id configuredobject = nil;

Tableviewcellconfigureblock block = ^ (Detialtableviewcell *a, id b) {

Configuredcell = A;

Configuredobject = b;

};

Arraydatasource *datasource = [[Arraydatasource alloc] initwithitems:@[@ "a", @ "B"] cellidentifier:@ "foo" Configurecellblock:block];

ID Mocktableview = [uitableview mock];

Detialtableviewcell *cell = [[Detialtableviewcell alloc] init];

__block ID result = NIL;

Nsindexpath *indexpath = [Nsindexpath indexpathforrow:0 insection:0];

It (@ "should receive cell request", ^{

[[Mocktableview should] receive: @selector (dequeuereusablecellwithidentifier:forindexpath:) Andreturn:cell witharguments:@ "foo", Indexpath];

result = [DataSource tableview:mocktableview Cellforrowatindexpath:indexpath];

});

It (@ "should return the Dummy cell", ^{

[[result should] equal:cell];

});

It (@ "should has Benn passed to the block", ^{

[[Configuredcell should] equal:cell];

});

It (@ "should has the same configured object", ^{

[[Configuredobject should] equal:@ "a"];

});

});

Context (@ "Number of rows", ^{

ID Mocktableview = [uitableview mock];

Arraydatasource *datasource = [[Arraydatasource alloc] initwithitems:@[@ "a", @ "B"] cellidentifier:@ "foo" Configurecellblock:nil];

It (@ "should be 2 items", ^{

Nsinteger count = [DataSource tableview:mocktableview numberofrowsinsection:0];

[[Thevalue (count) should] Equal:thevalue (2)];

});

});

});

Spec_end

Fourth chapter Xcode in instruments

Instruments is an automated test tool that comes with Xcode. It contains a lot of modules that can be tested on different aspects of the iOS app, but there are several common ones:

1.Leaks

Leaks can detect memory leaks, and the allocations trace template can see how memory is being used. In instruments, although the leaks template is selected, the Allocations template is added by default. Basically, the allocations template is used to analyze memory, which monitors the distribution of memory. Double-clicking the error location will directly find the error code location.

Usage Reference: http://cn.cocos2d-x.org/tutorial/show?id=1837

2.Automation

Tools for testing the UI, the UI test uses code to simulate event firings, and to make them appear to be really triggered by the user's behavior. If you encounter an error in your test, double-click the error to view the code error location.

Simple JS Login Script:

var target = Uiatarget.localtarget ();

var app = Target.frontmostapp ();

var MainWindow = App.mainwindow ();

Target.logelementtree ();

var Usertextfield = mainwindow.textfields () [0];

Usertextfield.setvalue ("admin");

Mainwindow.securetextfields () [0].setvalue ("admin");

var button = mainwindow.buttons () ["Login"];

Button.tap (); Click button

Automation has the recording function, after clicking on the recording to open the simulator to operate, Automation will automatically generate the JS code, we just need to test the module we need to add a for loop or other way you want to implement the test.

Usage Reference: http://www.th7.cn/Program/IOS/201404/192097.shtml

iOS Test summary