Unit test đi chờ chi :3

Lời chào

Xin chào các bạn, hôm nay cùng nhau bàn về về các vấn đề cơ bản của Unit Test (UT) nhé.

Mình sẽ nói về những vấn đề nổi bật mà bạn có thể dễ dàng nhận thấy được và không đi cụ thể vào chi tiết về tính chất và kỹ thuật của việc viết từng dòng UT nhé. Peace.

Let’s go 😗

Sự cần thiết và lợi ích

Đi thẳng vào vấn đề chúng ta có 2 câu hỏi lớn cần phải trả lời:

Có cần viết UT không?
- Việc viết UT có thể có hoặc không. Nó phụ thuộc vào nhu cầu và yêu cầu.
- Có những dự án chỉ viết UT. Có nghĩa bạn sẽ nhận được 1 cục mã nguồn và phải viết UT cho nó. Nếu may mắn thì bạn có tài liệu để đọc, bạn có thể tiếp cận và hiểu business, logic một cách dễ dàng hơn. Nếu không thì bạn sẽ khá lúng túng để hiểu những dòng code khô khan, nhưng trình độ đọc hiểu mã nguồn của bạn sẽ được nâng lên một tầm cao mới → Cá chép vượt vũ môn sẽ hoá rồng.
- Nếu viết code mà không có lỗi, hoặc lỗi ít, có thể chấp nhận được và nó không ảnh hướng đến tiến độ công việc → Có thể bỏ qua việc viết UT → Bạn viết code xịn (Đỉnh JOB).
UT có lợi ích gì?
- Với doanh nghiệp:
  - Việc giảm thiểu lỗi trong mã nguồn sẽ mang lại sự tin cậy, sự hài lòng từ người dùng sản phẩm.
  - Giảm các chi phí về thời gian phát triển, bảo trì và mở rộng hệ thống.
- Với lập trình viên:
  - Phát hiện sớm các lỗi: Phát hiện các lỗi do mã nguồn vừa viết hoặc các mã đã tồn tại bị ảnh hưởng (impact) bởi những dòng mã mới vừa viết.
  - Có thể coi UT là tài liệu của mã nguồn.
  - Giảm thời gian fix bug.
  - Nâng cao skill lập trình.
  - Việc viết code mà ít lỗi thậm chí không có lỗi đó là một niềm tự hào và có thể nhận được rất nhiều sự yêu quý từ đồng nghiệp (Đặc biệt là tester :3) và sự đánh giá cao của cấp trên. → Tăng 💵

Nên viết UT khi nào?

Unit Test cũng là mã nguồn. Nhưng viết nó trước hay viết sau khi thực hiện viết các tính năng thì nó ảnh hưởng rất nhiều bởi nhu cầu của doanh nghiệp và kỹ năng của lập trình viên.

Viết sau hoặc không viết:
- Khi thời gian phát triển có hạn/ gấp rút/ưu tiên release sớm.
- Đòi hỏi : Việc viết code phải đạt hiệu quả cao → Cũng phải có phân tích thiết kế → Có kiểm thử: Nhưng không thực hiện UT
- Lập trình viên có khả năng phân tích kém, chưa biết viết như thế nào. → Cứ viết trước, đụng đâu sửa đó.
Viết trước
- Hệ thống yêu cầu sự chính xác và hoàn chỉnh cao hơn là thời gian phát hành.
- Khi bạn có thể estimate được thời gian phát triển và không bị ràng buộc lớn về thời gian.
- Việc dành 1 khoản thời gian để phân tích có thể giúp chúng ta có một cái nhìn tổng quát về bài toán.
- Có thể liệt kê ra các check-list, trình tự phát triển.

Bắt đầu viết UT từ đâu?

Hãy bắt đầu từ những thứ đơn giản nhất như cái tên Unit Test → Hàm, Class,…
Những tính năng mà nhìn vào có thể hiểu được mà không cần tài liệu, comment nào.
Hãy bắt đầu từ những hàm ít phụ thuộc nhất.
Bắt đầu từ những trường hợp đơn giản nhất (Happy Case)

Cần làm gì khi viết UT?

Hiểu tính năng: Để xác định được mục đích, đầu vào và đầu ra của dữ liệu/ tính năng.
Tìm kiếm các lỗi có thể xảy ra / các ngoại lệ: Hãy thả lỏng cơ thể và tâm trí để tiếp cận các vấn đề từ những bước cơ bản nhất, khách quan nhất.
- Bạn có thể viết UT cho chính những dòng code của mình hoặc là của một đồng nghiệp khác. Vì những đồng nghiệp của chúng ta có kỹ năng và mind-set khác nhau nên đôi khi việc đọc hiểu trở nên khó khăn hoặc không theo ý của chúng ta là chuyện bình thường, nên hoan hỉ đón nhận vì đây là công việc :3 hoặc vừa code vừa chửi bới =))
Đưa ra solution: Khi tìm thấy các khả năng phát sinh ra lỗi thì cần đưa ra report về nó, nhiều hơn có thể đưa ra các solution.
Implement solution: Hãy viết ra một đoạn mã giải quyết vấn đề này và submit cho các bên liên quan (tạo Merge Request chẳng hạn).

Cần làm gì để viết UT hiệu quả?

Ở mức cơ bản hãy làm cho các đoạn code nhỏ, dễ hiểu và dễ đọc nhất.
Rèn luyện kỹ năng Debug.
Hãy tìm hiểu về clean code, các nguyên lý SOLID, design pattern, các cách tối ưu, refactor code. Để viết code có rõ ràng và có hệ thống hơn.
- Clean code → Dễ đọc, dễ maintain.
- SOLID → Dễ đọc, dễ maintain, dễ mở rộng.
- Design pattern → Dễ đọc, dễ maintain, dễ mở rộng, có tính hệ thống.
Luyện tập. Có những kỹ năng phải cần thời gian hoặc thậm chí rất nhiều thời gian để trở nên thành thục. Hãy kiên trì nhé.
Đọc code của các thư viện, mã nguồn lớn có tiếng để tiếp thu kiến thức từ họ.
Tìm người Review-Code. Những người có mind-set, tầm nhìn khác có thể chỉ ra những khía cạnh mà chưa mình thấy được. Hãy lắng nghe, suy nghĩ và cân nhắc.
Nếu viết UT có liên quan đến các thư viện bên thứ 3 mà bị bí (không biết viết như thế nào) thì làm gì?
- Thường thì các lib cũng sẽ có UT → nên tìm repo, mã nguồn của nó mà đọc.
- Lên các diễn đàn và đặt câu hỏi, để tìm ra hướng giải quyết phù hợp nhất.
- Đăng câu hỏi hoặc tìm kiếm trên Stack Overflow, Github Issue….

Làm sao để đo lường độ hiểu quả của UT?

Coverage: kiểm tra độ phủ của các UT với các dòng code (có nghĩa UT của bạn đã chạy qua được bao nhiêu dòng code trong thực tế sau khi kết thúc việc chạy UT). Thường thì sẽ có tool hổ trợ.
- Coverage 100% không có nghĩa là không có bug. Vì có thể bạn đã viết thiếu case và chỉ cover đủ cho các case bạn nghĩ ra. Hoặc có thể do sự phức tạp của dữ liệu và các luồng với nhau làm cho nó lỗi.
Đo lường thời gian code hoặc team productivity
- Thời gian phát triển tính năng bao gồm: phân tích → viết mã nguồn → kiểm thử → fix bug (lặp lại cho đến lúc release)
- Hãy đo lường khoảng thời gian thực tế đã dành ra trong từng giai đoạn. Nếu thời gian fix bug giảm đáng kể có nghĩa là đã có hiệu quả.
- Tuy nghiên thời gian phân tích và viết mã nguồn sẽ tăng lên. Nhưng đừng quá lo lắng. Việc phân tích tốt sẽ không chỉ giảm thời gian fixbug mà còn là thời gian maintain cho tương lai nữa. Nó cũng làm tăng khả năng estimate của bạn lên 1 tầm cao mới.
Đếm số lượng BUG
- Nếu dự án/tổ chức/team của bạn có quản lý task bằng jira, trello…(các công cụ) có thể lưu vết lại lịch sử bug thì có thể sử dụng nó để đo lường số bug mới và bug cũ.
- Hãy kiểm tra số lượng bug và nguyên nhân
  - Nếu bug bị lặp lại quá 3 lần → việc viết UT và quá trình tích luỹ kinh nghiệm có vấn đề và chưa hiệu quả.
  - Nếu bug mới: Hãy phân tích và ghi nhớ case đó. Có thể note lại, comment các case đặc biệt trong mã nguồn hoặc tài liệu nào đó. Và đặt mục tiêu sẽ không gặp lại nó trong tương lai 🥰

Lời kết

Cá nhân mình cảm thấy việc viết UT là điều cần thiết.

Nhưng viết UT cũng thật sự không dễ dàng.

Hãy cố gắng trao dồi và rèn luyện không ngừng bạn nhé.

Chúng ta có thể tiết kiệm thời gian fix bug để có nhiều thời gian làm việc khác như học thêm kiến thức mới, dành nhiều thời gian happy hơn bên gia đình, bạn bè và người yêu nhé 🥰