Hello Testing iOS

Chào mừng mọi người đến với Fx Studio. Chúng ta sẽ bắt đầu một chuyến phiêu lưu mới, nhưng lại với một chủ đề khá cũ. Đó chính là Testing trong iOS & Swift. Và tất nhiên, đây là phần không thể thiếu trong quá trình phát triển phần mềm nói chung. Chỉ có điều là các dev ngại va chạm nên không bao giờ viết test mà thôi.

Bài viết này sẽ mở đầu cho series Testing của Fx Studio, bên cạnh đó cũng là bài viết đầu tiên của một tác giả mới.

(Tâm Kun – aka Thích Va Chạm)

Mình là Tâm (kun) và những bài viết là những gì mà mình biết được, tìm hiểu được và đã trải qua được. Mình sẽ cố gắng truyền tải hết kiến thức và kinh nghiệm của mình cho các bạn mới bước vào nghề hoặc muốn tìm hiểu thêm. Còn những người đã có nhiều năm kinh nghiệm thì cũng có thể đọc để coi thằng “ranh con” này viết cái gì, nếu đúng thì gật gù vỗ tay còn sai thì “tương tác” để mình có thể khắc phục nhé.

Và nếu mọi việc đã ổn rồi, thì …

Bắt đầu thôi!

Chuẩn bị

Về mặt kiến thức, bạn cần biết được cơ bản về lập trình iOS & Swift. Vì có rất nhiều các thuật ngữ hay các khái niệm được sử dụng bài viết hay cả series này. Nếu bạn chưa biết gì về iOS & Swift, thì bạn có thể bắt đầu với link sau nhóe!

• Lập trình iOS cho mọi người

Về mặt công cụ, bạn chỉ cần có Xcode là xong nhóe. Bạn không cần quan tâm tới version Xcode, hay iOS … hầu như bạn sẽ sử dụng với các phiên bản mới nhất rồi.

Về mặt demo, Source code các ví dụ trong seri này các bạn có thể tham khảo ở đây. Trong đó có 3 file test chính:

• TutorialViewModelTest: Basic test.
• HomeViewModelTest: Test with Nimble/Quick.
• DetailViewModelTest: Test with OHHTTPStubs liên quan đến case server.

Testing và các thuật ngữ sử dụng

Testing là gi?

Mọi người chắc ai cũng biết “test” là gì đúng không?

Test là kiểm thử (theo google translate), thêm “ing” nữa là quá trình test, giai đoạn test.

Vậy trong Software development, thì nó được định nghĩa như thế nào?

Testing là một bước cực kì quan trọng trong quá trình phát triển phần mềm. Mục đích của testing là đảm bảo phần mềm chạy đúng yêu cầu của client hoặc yêu cầu đã được đặt ra từ trước.

Test in iOS

Nếu bạn là người lần đầu viết trong trong Xcode, thì chuỗi bài này sẽ giúp bạn hiểu được đâu đó về các bước phải làm để test được một app.

UnitTest

Lúc chém gió với bạn bè thì ta có thể nói:

Unit là đơn vị, test là kiểm thử. Vậy hiểu nôm na là kiểm thử từng đơn vị code.

Còn lúc phỏng vấn thì :

• UnitTest là phương pháp dùng để kiểm tra tính đúng đắn của một đơn vị source code.
• Đơn vị source code là phần nhỏ nhất có thể test được của chương trình.

Tại sao phải viết UnitTest?

Bất kì bugs cũng sẽ tìm thấy dễ dàng và nhanh chóng.

Code mà được bao phủ bởi tests, thì có độ tin tưởng cao hơn nhiều so với không có test. Nếu một feature bị thay đổi, coder sẽ nhận ra nguồn gốc của sự việc liền.

Trường hợp này, coder sẽ tra “author” xem ai sửa code dẫn đến bug và “nói lời yêu thương” với đồng nghiệp. Ahihi!

UnitTest tiết kiệm thời gian và tiền bạc.

Khi mà UnitTest đã hoàn thành, nhiều bug được tìm thấy phase này và có thể ngăn chặn nó ở phase tiếp theo và giúp ta “including” sau khi release. Nó giúp tiết kiệm chi phí đồng thời cũng mang lại lợi ích cuối cùng cho các user.

UnitTest cải thiện độ bao phủ của code (code coverage)

Đó là những tác dụng chính của việc viết UnitTest.

Các loại UnitTest trong iOS

Xcode cung cấp 3 kiểu test chính.

1. Functional Test: tập trung test các hàm (function). Ví dụ: Test các func xử lí logic, test số lượng cell trong một section, test số lượng section trong một TableView, test data từ server trả về có đúng không nè … nhiều lắm v.v.
2. Perfomance Test: tập trung và khả năng thực thi các task trên các thiết bị khác nhau. Ví dụ: Test task đó chạy trên IP13 Pro Max Mạ Kim Cương có đúng yêu cầu đề ra không?
3. UI Test: tập trung vào những tác vụ của người dùng trên giao diện.

Những bài tiếp tiếp theo, mình sẽ tập trung vào Functional Test, còn 2 loại kia nếu có thời gian thì mình sẽ đi sâu vào nhé.

UnitTest với MVVM

Tại sao thường sử dụng MVVM để viết UnitTest?

Những bạn nào đã từng làm dự án theo mô hình MVVM có thể hiểu nguyên nhân. Còn bạn nào chưa biết, thì đọc lại bài viết về mô hình MVVM ở đây nhé.

Mình giải thích ngắn gọn như sau:

Điểm mạnh của mô hình MVVM nằm ở ViewModel, nơi mà phân tích logic giữa View & Model. Nó giúp cho code được rành mạch và rõ ràng hơn.

Nên nó có thể hỗ trợ viết UnitTest rất tốt.

Tạo một file test

Bạn hãy mở project demo hoặc bạn có thể sử dụng project của chính bạn nhóe. Chúng ta sẽ tiến hành theo các bước sau.

Bước 1: Vào thư mục Test -> NewFile -> Unit Test Case Class -> Next

Bước 2: Đặt tên cho file test.

Ở đây ta có ViewModel có tên là TutorialViewModel, thì file test ta đặt TutorialViewModel cho dễ phân biệt.

Bước 3: Bước này rất quan trọng, các bạn nhớ tick Targets Tests nhé.

Nếu bạn tạo theo thứ tự như trên, thì Xcode mặc định tick cho bạn.

Bước 4: Nhấn create thì ta đã tạo file test thành công.

Thực thi Test

Sau khi, bạn đã tạo thành công một file test, thì chúng ta sẽ tới bước thực thi chúng. Đây chính là công việc chính mà bạn cần phải làm. Chúng ta sẽ có 3 cách cơ bản để thực thi như sau:

• Cách 1: Product -> Test hoặc nhấn Command-U.

• Cách 2: Click ở Test navigator
  • Success:

• • Failure

• Cách 3: Nhấn button bên trái class test.

EZ Game!

Basic example

Để giúp bạn có thêm cái nhìn khái quát nữa, thì ta sẽ thực hiện một ví dụ viết test cho 1 project với mô hình MVVM nhóe!. Ở đây mình tạo một ViewModel chứa một hàm xử lí logic cơ bản để giúp các bạn hiểu rõ nhất về test từng case nhỏ nhất nhé.

Chuẩn bị

Ta có code như sau:

enum Rank {
    case bad
    case middle
    case good
    case verygood
    case error
}

class TutorialViewModel {

    func rankStudent(point: Float) -> Rank {
        switch point {
        case 0.0 ... 4.9:
            return .bad
        case 5.0 ... 6.9:
            return .middle
        case 7.0 ... 8.4:
            return .good
        case 8.5 ... 10.0:
            return .verygood
        default:
            return .error
        }
    }
}

Nhìn vào hàm rankStudent() ta dễ dàng nhìn vào số case chúng ta cần phải test đúng không nào?

Phụ thuộc vào điểm số, thì chúng ta có tổng cộng 5 case cần phải test: bad, middle, good, verygood và error để nó có thể bao phủ toàn bộ logic của chúng ta.

File Test

Bạn sẽ thực hiện lại các bước trên và ta sẽ có code ví dụ cho file test như sau:

import Nimble
import Quick

@testable import FinalProject

class TutorialViewModelTest: QuickSpec {
    
    override func spec() {
        var viewModel: TutorialViewModel!
        
        beforeEach {
            viewModel = TutorialViewModel()
        }
        it("Test case rank bad") {
            expect(viewModel.rankStudent(point: 3)) == .bad
            expect(viewModel.rankStudent(point: 3)).to(equal(.bad))
        }
        it("Test case rank middle") {
            expect(viewModel.rankStudent(point: 6)) == .middle
            expect(viewModel.rankStudent(point: 6)).toNot(equal(.bad))
        }
        it("Test case rank good") {
            expect(viewModel.rankStudent(point: 8.2)) == .good
            expect(viewModel.rankStudent(point: 8.2)).toNot(equal(.middle))
        }
        it("Test case rank verygood") {
            expect(viewModel.rankStudent(point: 8.6)) == .verygood
            expect(viewModel.rankStudent(point: 8.2)).toNot(equal(.middle))
        }
        it("Test case rank error") {
            expect(viewModel.rankStudent(point: 11)) == .error
        }
        afterEach {
            viewModel = nil
        }
    }
}

Các bạn tạm bỏ qua các râu ria và setup các thứ nhé. Mình sẽ giải thích kĩ hơn về những thứ này ở bài tiếp theo khi chúng ta tìm hiểu về Nimble/Quick. Chúng ta tập trung vào các expect có trong code nhé.

expect là kì vọng, mong muốn, đoán trước (theo google transle)

Thực thi

Vậy nên chúng ta cũng đoán được câu lệnh này kiểm thử các kết quả trả về có đúng với specs của client hay đơn giản là logic code của chúng ta. Ví dụ:

• Input: Học sinh được 3 điểm.
• Output: Đạt danh hiệu học sinh kém.

it("Test case rank bad") {
    expect(viewModel.rankStudent(point: 3)) == .bad
    expect(viewModel.rankStudent(point: 3)).to(equal(.bad))
}

Ta thấy được điểm 3 nằm trong khoảng 0 .. 4.9 nên rõ ràng nó sẽ rời vào trường hợp .bad đúng không nào. Ahihi!

Tương tự với các case còn lại, thì ta được kết quả test như sau:

Độ bao phủ đã “xanh” ở toàn bộ ViewModel.

Còn nếu chúng ta đổi kết quả dự đoán từ bad sang good thì:

Hoặc thiếu một case test thì:

Khi bạn run test thì nó vẫn thành công nhưng nó lại không bao phủ tất cả các case. Nên bạn phải thêm case còn thiếu để phủ sóng hết test case.

Tạm kết

• Giới thiệu về Testing trong iOS và các thuật ngữ đi kèm
• Hướng dẫn cơ bản với việc tạo & thực thi file test trong project
• Thực hiện ví dụ về test case cho file ViewModel trong mô hình MVVM

Đây là bài hướng dẫn cơ bản đầu tiên để giới thiệu và khởi tạo các file test và ví dụ cơ bản để các hiểu được các case test như thế nào. Bài tiếp theo mình sẽ hướng dẫn viết test chi tiết hơn.

Okay! Tới đây, mình xin kết thúc bài viết về Hello Tesing trong iOS . Nếu có gì thắc mắc hay góp ý cho mình thì bạn có thể để lại bình luận hoặc gởi email theo trang Contact.

• Bạn có thể checkout source code tại đây.
• Bài viết tiếp theo tại đây.

Cảm ơn bạn đã đọc bài viết này!

Written by Tâm Kun