High Performance iOS Apps Testing and Release

Slides for the chapter Testing and Releasing in the book High Performance iOS App.

Transcript

1. Testing & Release High Performance iOS App @qcl 2016.09.08
2. 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
3. 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.
4. 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
5. Unit Testing • XCTest testing framework • Setup ◦ File > New > Target
6. 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.
7. Unit Testing
8. Unit Testing Test fixture Test case Setup object before testing the state ㄅ ㄅ
9. 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
10. Asynchronous Operations Get an XCTestExpectation instance Once done, mark the expectation to be fulfilled Wait.
11. Performance Unit Tests • measureBlock
12. 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)
13. OCMock Mock an object of HPSyncService class Stub sharedInstance method Stub fetchType:withId:completion
14. OCMock Verify those methods were called with specific parameter values.
15. Other Frameworks Framework type Name Mock objects OCMock OCMockito Matchers Expecta OCHamcrest TDD/BDD Specta Kiwi Cedar Calabash
16. Functional Testing • Instruments > Automation • Enable UI Automation on real device.
17. UI Automation • Using recorder
18. UI Automation Project Structure - tests - allTests.js - testScenaiorA - testA.js - testB.js - testScenaiorB - testC.js - testD.js • #import other files in allTests.js
19. Testing and Component Design • Testing / testing framework may impact component design.
20. 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.
21. Continuous Integration and Automation • Travis • Jenkins
22. 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.