标签：nbsp until least running table roc 原创 值类型 ever
A baseline is a combination of the average time performance in ten runs of the test method with a measure of the standard deviation of each run.
执行一次性能测试时，measureBlock内的代码会被执行十次！
When you start to create tests, keep the following ideas in mind:
When creating unit tests, focus on testing the most basic foundations of your code, the Model classes and methods, which interact with the Controller. 单元测试需要对每个细小的代码单元进行测试，单元的划分需要合理。
When creating UI tests, start by considering the most common workflows. Think of what the user does when getting started using the app and what UI is exercised immediately in that process. Using the UI recording feature is a great way to capture a sequence of user actions into a UI test method that can be expanded upon to implement tests for correctness and/or performance.
UI tests of this type tend to start with a relatively coarse-grained focus and might cut across several subsystems; they can return a lot of information that can be hard to analyze at first. As you work with your UI test suite, you can refine the testing granularity and focus UI tests to reflect specific subsystem behaviors more clearly.UI测试，按照最平常的操作流程写测试代码，考虑界面应该如何正确响应，多次测试之后再慢慢去细化测试的每个部分。
For each class, testing starts by running the class setup method. For each test method, a new instance of the class is allocated and its instance setup method executed. After that it runs the test method, and after that the instance teardown method. This sequence repeats for all the test methods in the class. After the last test method teardown in the class has been run, Xcode executes the class teardown method and moves on to the next class. This sequence repeats until all the test methods in all test classes have been run.
每个测试类开始执行时，都会先执行setUp类方法，然后开始执行每个测试方法。
执行每个测试方法时，都会先执行这个测试类实例对象的setUp方法，然后开始执行这个测试方法，在这个测试方法执行结束后，会执行这个测试类实例对象的tearDown方法。
这个类里面的所有测试方法执行结束之后，会执行这个测试类的tearDown类方法。
然后一直重复这个过程，直到所有的测试类都执行完测试方法位置。
简单来说，这个顺序从前往后就是：class func setUp() , func setUp() , func testFunc() , func tearDown() , class func tesrDown() 。
The Swift access control model, as described in the Access Control section of The Swift Programming Language (Swift 4), prevents an external entity from accessing anything declared as internal in an app or framework. By default, to be able to access these items from your test code, you would need to elevate their access level to at least public, reducing the benefits of Swift’s type safety.
Xcode provides a two-part solution to this problem:
When you set the Enable Testability build setting to Yes, which is true by default for test builds in new projects, Xcode includes the -enable-testing flag during compilation. This makes the Swift entities declared in the compiled module eligible for a higher level of access.
When you add the @testable attribute to an import statement for a module compiled with testing enabled, you activate the elevated access for that module in that scope. Classes and class members marked as internal or public behave as if they were marked open. Other entities marked as internal act as if they were declared public.
Note: @testable provides access only for internal functions; file-private and private declarations are not visible outside of their usual scope when using @testable.
对于Swfit代码的测试存在读取控制权限问题，所以苹果提供了两步解决办法来提升代码当前的存取控制权限。
第一步是去Xcode里面设置Enable Testability，第二步是在测试代码里添加@testable。对于fileprivate和private，@testable无法提升他们的访问权限。
For Objective-C, assertions marked for scalar types can be used with the types that can be used with the equality comparison operators: ==, !=, <=, <, >=, and >. If the expression resolves to any C type, struct, or array comparison that works with these operators, it is considered a scalar. 使用Objc写测试代码时，要注意值类型和引用类型的区别，而Swift不用。
Using XCTest assertions in your tests also differs between Objective-C and Swift because of how the languages differ in treating data types and implicit conversions.
For Objective-C, the use of implicit conversions in the XCTest implementation allows the comparisons to operate independent of the expressions’ data types, and no check is made of the input data types.
For Swift, implicit conversions are not allowed because Swift is stricter about type safety; both parameters to a comparison must be of the same type. Type mismatches are flagged at compile time and in the source editor.
Swift对于类型不匹配会报编译错误，进行Assert比较的变量必须类型匹配；Objc不会检查类型！
Here are some common issues to keep in mind:
Is the logic of the test correct? Is the implementation correct? 逻辑是否正确？实现是否正确？字面量有没有打错？
It’s always a good idea to check for typos and incorrect literal values that you might be using as the reference standard that the test method is using as a basis of comparison.
What are the assumptions? 多定义一些错误类型，写测试的时候也有可能传错数据
For example, you might be using the wrong data type in the test method, creating a range error for the code you’re testing.
Are you using the correct assertion to report the pass/fail status? 有没有用错Assetion？
For example, perhaps the condition of the test needs XTCAssertTrue rather than XCTAssertFalse. It’s sometimes easy to make this error.
Ficow原创，转载请注明出处：http://www.cnblogs.com/ficow/p/7859646.html
标签：nbsp until least running table roc 原创 值类型 ever
原文地址：http://www.cnblogs.com/ficow/p/7859646.html
