Unit test, dev nên quan tâm những gì

Bài đăng này đã không được cập nhật trong 4 năm

Vì sao cần quan tâm unit test, đơn giản là để tránh bị những bug đáng ra không nên bug :v, đùa thôi, nói chung là xác định xem phần mềm được tạo ra có hoạt động đúng như mong đợi hay không
unit test là phần thấp nhất trong các tầng của testing, được xử lý bởi dev

Đối với dev khi viết unit test thì chỉ cần quan tâm tới scope là được
- Validation check (error message, required fields, max length...)
- P1 test cases: Happy path flow
- P3 test cases: Components
- Functionality Test
- Role and permission
Còn những gì ngoài scope, quan tâm được thì càng tốt :v (hoặc nếu bị bắt buộc =)))
- UI / UX
- Non functional testing: Usability, Performance/Stress/Load test...
- Abnormal case
- Enhancement

TDD thì mọi người nghe nhiều rồi: Test Driven Development, viết test trước khi code
ATDD (Acceptance Tést Driven Development) BDD (Behaviour Driven Development) thì là nâng cao hơn của TDD
Mình thấy 2 thằng khá tương đồng:
- Đều dựa theo story mà KH cung cấp
- Sau khi có story, các bên liên quan: Dev, QA, Tester, PM, ... sẽ cùng ngồi xuống và nói chuyện với nhau về story này
- Chia thành 3 phần
  - Give: Nhận được gì
  - When: Khi nào thực hiện
  - Then: Sau đó thì sao
- Sau đó áp dụng TDD
Video về ATDD: https://www.youtube.com/watch?v=uPgTvZO5laY&ab_channel=VladimirMandala
Video về BDD: https://www.youtube.com/watch?v=ydddSkVz_a8&ab_channel=MarkShead

Decisions Table

Ta có bài toán về mở thẻ tín dụng, với các điều kiện được cho sau đây
- Nếu khách hàng mới và muốn mở tài khoản thẻ tín dụng sẽ được giảm giá 15%
- Nếu đã là khách hàng và có thẻ loyalty => được giảm giá 10%.
- Và nếu khách hàng có phiếu mua hàng thì sẽ được giảm giá 20%
- Không áp dụng đồng thời với điều kiện giảm giá cho khách hàng mới
- Các khoản giảm giá được cộng dồn (nếu áp dụng)
Theo cách làm cũ, ta sẽ tự suy nghĩ các TH có thể xảy ra :v, nhưng phía tester sẽ có công thức để tính ra
Đầu tiên là list các điều kiện có thể xảy ra
- KH mới
- KH có Loyalty card
- KH có coupon
ta lấy 2 mũ với số điều kiện sẽ ra các case cần: 2^3 = 8

Vậy ta có 8 case cần kiểm tra

Điều kiện	TH 1	TH 2	TH 3	TH 4	TH 5	TH 6	TH 7	TH 8
KH mới	T	T	T	F	F	T	F	F
KH có Loyalty card	T	T	F	T	T	F	F	F
KH có coupon	T	F	T	T	F	F	T	F
-	-	-	-	-	-	-	-	-
Giảm giá	x	x	20	30	10	15	20	0

Qua bài toán nâng cao hơn: Bảo hiểm xe
- Với nữ dưới 65 tuổi: bán 500$
- Với nam dới 25 tuổi: bán 3000$
- Với nam từ 25 tới 64: bán 1000$
- Với cả nam lẫn nữ trên 65 tuổi: bán 1500$
Tổng cộng ta sẽ có 5 điều kiện
- Nam
- Nữ
- < 25
- >= 25 và < 65
- >= 65
Nếu dùng công thức 2 ^ với số điều kiện thì ta có tới tận 25 test case để check @@
Nhưng trên thực tế có những TH sẽ không bao giờ xảy ra: giới tính không thể vừa nam vừa nữ, không thể không có giới tính, nhỏ hơn 25 thì không lớn hơn 25 được, ...

Rút gọn lại ta chỉ cần test 6 TH là đủ

Điều kiện	TH 1	TH 2	TH 3	TH 4	TH 5	TH 6
Nam	T	T	T	F	F	F
Nữ	F	F	F	T	T	T
< 25	T	F	F	T	F	F
>= 25 và <65	F	T	F	F	T	F
>= 65	F	F	T	F	F	T
-	-	-	-	-	-	-
Giá bán	3000	1000	1500	500	500	1500

Statement coverage là cover code của mình đã chạy hết chưa
Hiện tại có rất nhiều tool support cho phần này
Decision coverage là cover thêm các TH mà trong code không có như trong code chúng ta chỉ có như sau
```
if (gender === 'male') { discount = '10%' }
```
thì nếu chỉ statement coverage thì pass đoạn code if đó là ok
nhưng decision coverage là chúng ta sẽ test thêm các đoạn else của if trên, xem xem sẽ có gì xảy ra, và nó xảy ra theo đúng ý của mình hay chưa

Còn có rất nhiều thứ để có thể test được, nhưng đối với dev thì mình thấy chừng này là đủ sài để có thể viết unit test một cách xịn xò nhẩt rồi :v
Mọi người nên tập làm quen dần với việc cover đủ unit test, vì nếu sau này có change request xảy ra, khi chạy tổng, những chổ nào bị ảnh hưởng sẽ được unit test thể hiện