Slide 1

Slide 1 text

Testing & Release High Performance iOS App @qcl 2016.09.08

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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.

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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.

Slide 7

Slide 7 text

Unit Testing

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

Performance Unit Tests ● measureBlock

Slide 12

Slide 12 text

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)

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

OCMock Verify those methods were called with specific parameter values.

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

UI Automation ● Using recorder

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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.

Slide 21

Slide 21 text

Continuous Integration and Automation ● Travis ● Jenkins

Slide 22

Slide 22 text

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.