Hi thereeeeee! ❤ ❤ ❤
Thật ra mình cũng lười… :D cũng không định viết gì lắm. Mà hôm nay có một thứ làm mình thấy hay vcllllllll nên quyết định viết vài dòng take note :P
Như title, thì bài viết này mình sẽ… không đề cập gì đến unit testing cả :troll: vì đơn giản unit test là vấn đề được nói đi nói lại đến hàng trăm lần từ người này tới người khác, từ lợi ích của unit test cho tới làm thế nào để viết unit tests một cách bài bản và hiệu quả :3 cho nên mình cũng k có hứng đi viết lại những thứ cũ kỹ (ít nhất là với mình).
Thôi tóm lại unit test là thứ không thể thiếu trong software development. Nên mình rất thích một cái quote. Không nhớ chính xác nhưng đại khái là.
Code that cann’t be tested is the code easily to be broken
Vấn đề mình muốn nói tới là cụ thể unit test hoạt động như thế nào với XCTest :D
Lets go!
Nhưng thông khi bắt đầu một unit test (unit ở đây thường sẽ là một class), chúng ta sẽ bắt đầu với việc import XCTestframework, tạo một XCTestCasesub-class, setUp, viết test method rồi tearDown.
import XCTestclass YourTestClass: XCTestCase {
func setUp() { // setup sut and dependencies } func tearDown() { // release sut and dependencies } func testSth() {
// testing something
}}class YourTestClass1: XCTestCase { // same thing }class YourTestClass2: XCTestCase { // same thing }// saaaaameeee thiiiiiiiing
Thử tưởng tượng là bạn sẽ có bao nhiêu class trong một project… chỉ nói các class để handle business logic (thường sẽ được expect là code coverage 100%). Đối với một project nhỏ lẻ cá nhân thì sẽ không sao. Nhưng đối với một project với cả trăm thậm chí cả ngàn layer như project mình đang làm (siêu-to-khổng-lồ project) thì bạn cũng sẽ có bấy nhiêu TestClass tương ứng … YourTestClass1 -> YourTestClassN (hãy quan tâm là N là số rất lớn).
Thứ mình muốn nói đến thật ra không phải là việc nhiều hay ít test cases. Nhưng mình muốn nói để cái lỗi mọi người viết unit test thường mắc phải :P
Đó là mọi người thường không sử dụng setUp và tearDown
Vậy thì vấn đề ở đây là gì???
Chắc mọi người vẫn nhớ là sẽ như thế nào nếu chúng ta sử dụng bộ nhớ mà không release (out of memory -> OS force crash). Nhưng đó là một thứ đã quá cũ tại sao mình lại để cập đến… trong khi chúng ta đã có ARC và nghe cũng chẳng liên quan gì đến setUp với cả tearDown :D
Hmm nói một chút về XCTestCase. Control flow khi một test function (func testSth())được chạy sẽ theo các bước (đại khái) như sau.
do { setUp()
try testSth()
tearDown()} catch {
print(error) // error from XCAssert in testSth()
}
Behind the scene, khi chúng ta bắt đầu run một test suite (cmd + u)…. à thôi dài dòng qúa :( lườiiiiii.
Nói dễ hiểu xúc tích, khi chúng ta run test cases, XCTest sẽ bắt đầu với việc query tất cả subclass của XCTestCase, mỗi class sẽ query tất cả các methods: không có param, không có return value, và prefix là test. Vấn đề ở đây là sau khi query các test classes XCTest sẽ init luôn tất cả test classes và save trong memory và sẽ không bao giờ release cho đến khi tất cả test cases (khoảng 1000 XCTestCase sub-class) đc chạy xong. Như vậy nếu chúng ta không release sut & dependencies trong tearDown thì nó sẽ tồn tại cho đến khi hết test cases. Để dễ hiểu thì mình sẽ nói là mỗi XCTestCase class sẽ có một method, nó cũng tương tự cho việc có nhiều method, thì sau khi method cuối cùng chạy xong mà không release trong tearDown thì nó vẫn còn ở đó.
Nói tóm lại có 2 kết luận như sau:
- Những gì được init cùng với test class (k phải trong setUp) sẽ có trước khi chúng ta thực sự chạy test.
class DumbassTests: XCTestCase {
var dependency1 = Dependency1()
var dependency2 = Dependency2()
}
// dependencies will exist too soon.- Những gì k được release trong tearDown sẽ tiếp tục tồn tại.
Nếu bạn có một tập test cases lớn sẽ dẫn đến crash khi chưa chạy hết tests hoặc trong test có sử dụng swizzling thì sẽ xảy ra nhiều trường hợp k mong muốn.
Thật ra là có cách khác để tránh trường hợp này :( cứ init tất cả dependencies trong test method là xog :( nhưng mà cách này có vẻ k Swifty cho lắm :( nhìn cùi cùi nữa.
Hix nói tới đây mình cũng chả biết ý nghĩ của bài này là gì…chỉ là mà mình quá buồn ngủ rồi nên type đại type càng cho xog :(( Thôi vậy coi như mọi người biết thêm một best practice. PEACEEEE mình ngủ đây. THANKSSSS
// Chú thích
Test classes: XCTestCase
Test methods: method của test class.
XCTest là framework
