iOS Testing with Xcode 閱讀筆記
Performance Testing
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內的代碼會被執行十次！
Where to Start When Testing
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測試，按照最平常的操作流程寫測試代碼，考慮界面應該如何正確響應，多次測試之后再慢慢去細化測試的每個部分
Flow of Test Execution
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() 。
Writing Tests with Swift
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 Testabilitybuild setting toYes, which is true by default for test builds in new projects, Xcode includes the-enable-testingflag during compilation. This makes the Swift entities declared in the compiled module eligible for a higher level of access. -
When you add the
@testableattribute 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無法提升他們的訪問權限。
Using Assertions with Objective-C and Swift
-
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不會檢查類型！
Test Debugging Workflow
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
XTCAssertTruerather thanXCTAssertFalse. It’s sometimes easy to make this error.
Enable Code Coverage
Code coverage data collection incurs a performance penalty. Whether the penalty is significant or not, it should affect execution of the code in a linear fashion so performance results remain comparable from test run to test run when it is enabled. However, you should consider whether to have code coverage enabled when you are critically evaluating the performance of routines in your tests.
代碼覆蓋率會影響性能測試的結果。
Writing Testable Code
-
Define API requirements. It is important to define requirements and outcomes for each method or function that you add to your project. For requirements, 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.
See the Unit Testing Apps and Frameworks sample-code project for an example of using exceptions to identify and report incorrect library usage by client code. 盡可能避免使用全局變量，傳參到方法里然后返回某種類型的結果
-
Write test cases as you write code. As you design and write each method or function, write one or more test cases to ensure that the API’s requirements are met. Remember that it’s harder to write tests for existing code than for code you are writing. 盡早寫測試代碼，寫一個方法就寫對應的測試代碼，為已有的代碼寫測試極其痛苦！
-
Check boundary conditions. If a parameter for 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 that can have values between
0and100, inclusive, the test code for that method should pass the values0,50, and100for 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
0to100, inclusive, create test cases that pass the values-1and101to 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. Although simple, isolated tests provide value, stacked tests exercise complex behaviors and tend to catch many more problems. These kinds of tests mimic the behavior 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 are correct. 將測試用例綜合起來進行測試，有些測試用例分開進行時沒問題，結合起來就發生了故障
-
Cover your bug fixes with test cases. Whenever you fix a bug, write one or more tests cases that verify the fix. 修復BUG之后，完善BUG對應的測試用例
Ficow原創，轉載請注明出處：http://www.rzrgm.cn/ficow/p/7859646.html
浙公網安備 33010602011771號