Testing & Release High Performance iOS App @qcl 2016.09.08 

Test Types ● Unit testing ○ Testing an iolated method in a simulated environment to ensure validity ● Functional testing ○ Testing a method in a real-world scenario for accuracy ● Performance testing ○ Testing a method, a module, or a complete app for performance 

Definitions ● Test case ○ A scenario that needs to be tested. ■ Condiction under which method, feature, or application will execute. ■ A set of inputs, or required in the scenario being tested. ■ Expected behavior, include ouputs or changes to the system. ● Test fixture ○ Represent the preparation needed and any associated cleanup to be done to pefrom test case(s). ■ Object creation, dependency setup, database configuration. ● Test suite ○ A collection of test fixtures with the test cases. ○ It’s used to aggregate tests taht should execute together. 

Definitions ● Test runner ○ A system that executes the test cases. ● Test report ○ The summary of which tests executed successfully and which failed. ● Test coverage ○ Measure the amount of testing performed by a test suite and is useful to find untested parts of the app. ● TDD ○ Test-driven development. ■ Writing automated test cases ■ Writing minimal code to pass these tests ■ Refactoring the code to acceptable standards and quality 

Unit Testing ● XCTest testing framework ● Setup ○ File > New > Target 

Unit Testing ● + setUp ○ Test fixture setup method, called before any test case in the class executes ● - setUp ○ Test case setup method, called before each test case executes. ● - testXXX ○ All instance methods with prefix test without any parameters are test cases taht get executed. ● - tearDown ○ Test case cleanup method, called after each test executes. ● + tearDown ○ Test fixture cleanup method, called after all test cases in the class execute. 

Unit Testing 

Unit Testing Test fixture Test case Setup object before testing the state ㄅ ㄅ 

Code Coverage ● External coverage report ○ Turn on following flags ■ Generate Debug Symbols ■ Generate Test Coverage Files ■ Instrument Program Flow ○ This will generate the .gcno and .gcda files ■ .gcno has details to reconstruct the basic block graphs and assign source line number to blocks. ■ .gcda file contains the ARC transition count. ○ lcov, genhtml 

Asynchronous Operations Get an XCTestExpectation instance Once done, mark the expectation to be fulfilled Wait. 

Performance Unit Tests ● measureBlock 

Dependency Mocking ● - setUp method is where dependencies will be configured. ● Will be reset in - tearDown method. ● Stub ○ Provide canned answer to calls made during the test. ● Spy ○ Captures and makes available parameter and state information. ● Mock ○ Mimics the behavior of a real object in a controlled manner. ● Fake ○ Works identically to the original object, except that it fakes out the underlying implementation. (e.g. fake DB) 

OCMock Mock an object of HPSyncService class Stub sharedInstance method Stub fetchType:withId:completion 

OCMock Verify those methods were called with specific parameter values. 

Other Frameworks Framework type Name Mock objects OCMock OCMockito Matchers Expecta OCHamcrest TDD/BDD Specta Kiwi Cedar Calabash 

Functional Testing ● Instruments > Automation ● Enable UI Automation on real device. 

UI Automation ● Using recorder 

UI Automation Project Structure - tests - allTests.js - testScenaiorA - testA.js - testB.js - testScenaiorB - testC.js - testD.js ● #import other files in allTests.js 

Testing and Component Design ● Testing / testing framework may impact component design. 

Testing and Component Design ● If you have dependencies on other systems, you may want to create wrappers. ○ This helps in completely mocking out the dependencies during testing. ○ It may also help you in creating replaceable dependencies. 

Continuous Integration and Automation ● Travis ● Jenkins 

Best Practices ● Test all code, including all initializers ● Test againsts all combinations of the parameter values. ● Do not test private methods. Consider the method being tested as a black box. ● Prefer to stub out any external dependencies. ● Set up the state before each test and clear it after execution. ● Each test case should be repeatable. ● Each test case must have assertions to validate or invalidate the code being tested. ● Enable code coverage for the complete run.