swift-vietnam / meetup

0 stars 0 forks source link

Meetup 22/4: How to write unit test in iOS - @vanalite #3

Open TaPhuocHai opened 7 years ago

Vanalite commented 7 years ago

Link to the slide - Introduction to Testing on iOS.pdf

Link to the demo code

Introduction to testing on iOS

About modern software development (3 mins)

Why is it necessary? (5 - 10mins)

Testing concepts (5 mins)

Unit testing

Tests the smallest unit of functionality, typically a method/function

Integration testing

Integration tests build on unit tests by combining the units of code and testing that the resulting combination functions correctly. The difference between integration tests from unit tests is the environment.

Functional testing

Functional tests feed input to the user interface, and make assertions about the output that ensure that the software responds the way it's supposed to do from the user's perspective.

Unit testing on iOS (5 - 10 mins)

Apple provides XCTest framework from XCode 5, derived from OCUnit

What to test
What not to test

Demo (20 mins)

Brief look on XCTest

Developed by Apple itself, to create and run unit tests, performance tests, and UI tests for your XCode project.

Understanding the low level process of iOS testing framework
Tesing a static function
Tesing an instance function

Quick/Nimble demonstration

Quick is a testing framework built on top of Apple's XCTest to write test in a style similar to Ruby's RSpec.

While Nimble is a library of composable matchers wrapping the XCAssert.

Together Quick and Nimble allow you to write more expressive tests, with a syntax that makes it easier to focus on the behaviour that is tested, and easy to write complex expectations.

Tesing a static function
Tesing an instance function
Testing an async task

Tips & convention for writing tests (15 mins)

Introduction to KIF to UI testing (5 mins)

Another testing framework that is built on top of XCTest is KIF (Keep it functional).

Imagine how to test a function lie at the deep level of the app. You would insane tap the same sequence of steps and terminate/relaunch app in order to reset to the initial state.

KIF leverage the Accessibility APIs in iOS to simulate user interaction on UI components. Built up on top of XCTest, KIF is easy to learn, supported for various iOS versions, and compatible with XCode.

Q/A

TaPhuocHai commented 7 years ago

@Vanalite How about personal experience do you have to share ? Ex: about design code structure, refactor, use more protocol, etc... ?

I am apply testing on my project. I have problem about how to design code structure to write test. Because if I write code as I usually do, I can't write test for it.

TaPhuocHai commented 7 years ago

Can you talk a little about KIF to write UI test ?

Vanalite commented 7 years ago

@TaPhuocHai basically, it's hard to achieve 100% unit test coverage. Some famous design patterns in iOS development, such as Singleton, counter unit testing capability. There is some technique to bypass such problem, but let me just mention a little bit about it in the talk.

KIF is for integration test. Are you sure to let me introduce it in my session? I only have 45mins, though.

TaPhuocHai commented 7 years ago

@Vanalite I really want to hear your experience about design patterns in iOS for testing. About KIF, I think you should have about 10 minutes to introduce it.

We can flexible to 1 hour :)

Vanalite commented 7 years ago

Updated! @TaPhuocHai, there are many techniques to be applied in writing test effectively. In the last section, I would like to dive deeper in testing framework under the hood, how it works, and what the difference is in the approaches from a testing framework to another. Understanding this low level of the framework seems to be useless in software development. However, most geeky would love to know.

On the other hands, that last section can be replaced by talking about some useful techniques to be used in writing test. The problem is, there are many domains that more than one technique can be applied. For instance: mocking objects, stubbing external resources, leveraging untestable code, test coverage, etc.

What would it be your comment for the last section?