Cách thực hiện unit test chi tiết và những lưu ý quan trọng

Với những ai hoạt động trong lĩnh vực công nghệ thông tin thì thuật ngữ Unit test không còn quá xa lạ. Đây là một loại kiểm thử phần mềm đóng vai trò quan trọng trong các dự án phát triển phần mềm, ứng dụng. Nếu bạn là một newbie mới bước chân vào nghề lập trình và còn thiếu nhiều kiến thức căn bản về unit testing thì hãy lưu lại bài viết dưới đây của TesterproVN nhé!

Unit Test là gì?

• Unit Test hay còn gọi là kiểm thử đơn vị được định nghĩa là một loại Software Testing. Trong đó các đơn vị hoặc thành phần riêng lẻ của phần mềm được kiểm tra nhằm xác định sự phù hợp của chúng. Đối với các thông số kỹ thuật cùng dữ liệu liên quan và quy trình sử dụng. Kiểm thử đơn vị là tiến trình bắt buộc phải có trong mọi quá trình phát triển của ứng dụng.

• Software Testing bao gồm 4 mức độ khác nhau theo thứ tự: SDLC, STLC, V Model và Unit Test. Trong đó Unit Test nằm ở mức độ thấp nhất và được tiến hành trước khi thực hiện integration test. Nó được thực hiện trong quá trình phát triển hoặc giai đoạn lập trình của một ứng dụng bởi các nhà phát triển. Các thành phần có trong kiểm thử đơn vị gồm: Function, method, class, module,…

• Quá trình kiểm thử đơn vị sẽ cô lập một phần code và tiến hành xác minh tính đúng đắn của nó. Đồng thời giúp bạn kiểm tra mọi mã nguồn có sẵn của các chương trình. Nó sẽ tạo ra các chứng năng riêng rẽ xem chúng có hoạt động đúng hay không. Unit Testing thường được thực hiện bởi các lập trình viên.

• Khi tiến hành kiểm thử đơn vị bạn sẽ bắt gặp một số khái niệm: Function Unit Test là gì, Assertion, Test Point, Test Suite, Regression Testing, Production Code, Unit Testing Code,… Mỗi khái niệm có vai trò riêng và sự liên quan nhất định đến quá trình kiểm thử.

Ý nghĩa của Unit Test trong kiểm tra thử phần mềm

• Khi quá trình kiểm thử đơn vị tốt thì sẽ giúp lập trình viên gia tăng được sự tin tưởng vào mã nguồn đã được bảo trì hoặc thay đổi.

• Hoàn toàn có thể phát hiện được những lỗi thường xảy ra do các thay đổi của mã nguồn khi viết Unit Test tốt.

• Bạn dễ dàng kiểm thử được các thành phần riêng rẽ của dự án mà không cần phải chờ các thành phần khác được hoàn thành.

• Vì thực hiện kiểm thử dựa trên từng đơn vị nhỏ của các module riêng nên khi phát hiện lỗi cũng dễ khoanh vùng và sửa chữa nhiều hơn.

• Với kiểm thử đơn vị thì bạn hoàn toàn có thể tái sử dụng mã nguồn.

• Chi phí cho việc sửa chữa lỗi trong giai đoạn Unit Test thường thấp hơn so với các giai đoạn bạn sử dụng phía sau.

• Bạn sẽ có được những mã nguồn đáng tin cậy hơn nếu thực hiện kiển thử đơn vị tốt.

• Đây là công cụ giúp bạn đánh gia năng lực cùng số lượng của các test case. Từ đó chuyển sang trạng thái pass và thể hiện được tốc độ làm việc và năng suất của bạn.

• Hỗ trợ giải phóng các chuyên viên QA ra khỏi các công việc kiểm tra phức tạp khác.

• Mang đến môi trường lý tưởng để người dùng có thể test bất kỳ đoạn code nào. Khi đó nó sẽ thăm dò để phát hiện ra lỗi chính xác hơn cùng duy trì sự ổn định cho toàn bộ PM. Thông qua đó giúp tiết kiệm thời gian tối đa so với công việc gỡ rối truyền thống.

• Tạo ra hàng rào an toàn cho các khối mã và bất kỳ sự thay đổi nào cũng sẽ tác động đến hàng rào này để thông báo cho những nguy hiểm có thể xảy ra.

• Có vai trò như tài liệu của dự án giúp tái sử dụng code. Chuyển cả code lẫn test sang dự án mới và chính sửa code cho đến khi các kiểm thử chạy lại giúp tiết kiệm thời gian.

• Phát hiện các thuật toán thực thi không hiệu quả và các thủ tục chạy vượt quá giới hạn thời gian. Đồng thời phát hiện các vấn đề về thiết kế, xử lý hệ thống cùng mô hình thiết kế.

Cách thức Unit Test hoạt động

• Để thực hiện kiểm thử đơn vị thì các lập trình viên sẽ viết đoạn code để kiểm tra chức năng (function) cụ thể trong ứng dụng phần mềm. Hoặc các developer có thể cô lập các function để kiểm tra kỹ hơn. Điều này cho thấy sự phụ thuộc không cần thiết giữa function được test và các đơn vị khác để có thể loại bỏ. Các lập trình viên thường dùng framework UnitTest để phát triển các test case tự động.

• Kiểm thử đơn vị được tiến hành theo 2 hình thức: thủ công và tự động. Tuy nhiên hình thức tự động hóa được yêu thích hơn. Bởi khả năng dễ dàng gắn cờ và báo cáo mọi trường hợp kiêm thử không thành công và cung cấp bản tóm tắt các test case. Cách thức tự động hóa này còn được gọi là Automated Unit Testing. Nó là quá trình test có sự hỗ trợ của công cụ giúp việc kiểm thử có độ chính xác cao.
• Như vậy bạn đã hiểu được Automated Unit testing là gì? Vậy phương pháp đưcọ áp dụng trong quy trình này kiểm thử đơn vị tự động là gì? Quy trình kiểm thử được áp dụng theo phương pháp White Box Test với 4 bước. Gồm: tập hợp đầy đủ dữ liệu cho qúa trình thử nghiệm (khởi tạo đối tượng, vùng kiểm tra,…). Tiếp đó bạn cần lựa chọn phương thức cần t kiểm tra và tiến hành khởi động. Kế tiếp bạn cần theo dõi, rà soát và kiểm tra sự hoạt động đúng đắn của từng phương thức. Sau cùng là kết thúc việc kiểm tra và dọn dẹp tài nguyên.

• Trong giai đoạn đầu tiên thì bài Unit Testing được chuẩn bị và xem xét. Tiếp đến là các trường hợp kiểm thử và tập lệnh được thực hiện và code sẽ được thử nghiệm. Các nhà phát triển cần phải viết các bài kiểm thử đơn vị bị lỗi rồi viết mã và cấu trúc lại ứng dụng cho đến khi hoàn thành kiểm thử.

• Khi các Unit trong một chương trình được phát hiện là đang hoạt động theo cách hiệu quả nhất và không có lỗi. Các thành phần của chương trình được đánh giá bằng phương pháp integration testing.

Ứng dụng của Unit Test

Loại kiểm thử này được áp dụng chính xác vào các công việc cụ thể gồm:

• Tiến hành test cho mọi đơn vị nhỏ nhất bao gồm: Function, method, class, module,…

• Kiểm tra mọi trạng thái cùng sự ràng buộc đối tượng ở mức độ sâu hơn của đối tượng. Nó là mức độ mà thông thường các lập trình viên khó có thể thực hiện truy cập vào chúng.

• Thực hiện test cho các quy trình cùng mở rộng hơn là thực hiện các khung làm việc được coi là tập hợp nhiều quy trình khác.

Đánh giá ưu nhược điểm của Unit Test

Ưu điểm

• Tạo ra những môi trường lý tưởng cho các hoạt động kiểm tra cùng khả năng khoanh vùng đơn vị nhỏ để nhanh chóng tìm ra lỗi code gặp phải ở hiện tại.

• Thăm dò tính khả quan của phương án thực thi cùng duy trù ổn định cho toàn hệ thống với cơ chế độc hoạt động độc lập. Nhờ đó giúp tiết kiệm thời gian hơn so với phương pháp truyền thống.

• Có sự nhạy cảm cao trong khi có những sự thay đổi đột ngột nào đó. Khi Unit Test nhận được tín hiệu không khả quan từ một khu vực thì nó sẽ nhanh chóng tạo ra lớp bảo vệ cho các khu vực khác.

• Với khả năng phát hiện ra những lỗi nhỏ nhất nhanh chóng trong các môi trường hẹp.

• Cung cấp những đánh giá về các bộ phận đang hoạt động không hiệu quả gồm: dự kiện hoặc các thủ tục chạy quá mức thời gian cho phép.

• Kiểm thử đơn vị giúp phát hiện ra các lỗi trong cấu trúc thiết kế. Nó được dùng như một công cụ để đánh giá chất lượng của chương trình và năng lực của người thực thi.

Nhược điểm

• Không phải các bài test đều có thể phát hiện ra tất cả các bug.

• Quá trình kiểm thử này chỉ test các tập dữ liệu và chức năng của nó chứ không tìm ra các lỗi tích hợp.

• Bạn cần viết nhiều dòng test code hơn để kiểm tra một dòng code.

• Các lập trình viên khi tiến hành kiểm thử đơn vị đòi hỏi phải có trình độ chuyên môn cao và dày dặn kinh nghiệm để tiến hành các Unit Test hiệu quả.

• Việc kiểm thử này sẽ mất nhiều thời gian do sự đồ sộ và phức tạp nên cần có một nhóm vận hành và quản lý. Tuy nhiệm vụ của kiểm thử đơn vị là phát hiện lỗi nhưng nó cũng mắc lỗi vởi người lập trình ra nó phạm sai lầm.

Kỹ thuật Unit Test bao gồm những gì?

Được phân loại thành 3 phần gồm: Black box testing (kiểm thử hộp đen) với chức năng kiểm tra giao diện người dùng cùng đầu ra và đầu vào. Whitebox testing (Kiểm thử hộp trắng) gồm kiếm tra hành vi chức năng của ứng dụng phần mềm. Còn Gray box testing (kiểm thử hộp xám) dùng để thực hiện: test suites, test methods, test cases và thực hiện phân tích rủi ro.

Code coverage là phương pháp đánh giá được dùng để mô tả mức độ mà source code của một chương trình đã được thực thi khi một bộ test cụ thể chạy. Nói cách khác thì nó đảm bảo tằng kiểm thử của bạn đang thực sự test Codes của bạn. Những kỹ thuật code coverage được sử dụng trong Unit Test gồm:

• Statement Coverage hay còn gọi là bao đảm bảo các dòng lệnh trong mã nguồn đã được kiểm tra ít nhất một lần trong Statement coverage = (số lượng lệnh code được kiểm tra / tổng số lệnh code) x100.

• Decision Coverage: với mỗi lệnh if, case, do – while,… được coi là một decision. Nó bao gồm 2 đầu ra là TRUE hoặc FALSE được gọi là decision outcome. Để đảm bảo 100% coverage thì mỗi đầu ra TRUE FALSE phải được test ít nhất 1 lần. Với công thức tính là Decision coverage = (Tổng số decision outcome được test / Tổng số decision outcome) x 100.

• Path Coverage: đảm bảo tất cả các đường có thể xảy ra đi từ điểm đầu đến điểm cuối được kiểm tra hết.

• Branch Coverage: được sử dụng để bao phủ tất cả các nhánh của đồ thi luồng điều khiển. Nó gồm tất cả kết quả có thể xảy ra (đúng hoặc sai) của mỗi điều kiện của điểm quyết định ít 1 lần. Đây là một ký thuật kiểm tra hộp trắng đảm bảo mọi nhánh của mỗi điểm quyết định phải được thực thi.

• Condition Coverage: Gồm tỷ lệ của điều kiện đầu ra đã được thực thi bởi bộ kiểm thử. 100% điều kiện bao phủ (condition coverage) yêu cầu mỗi điều kiện đơn riêng lẻ trong mỗi câu quyết định (decision statement) phải được thực thi như là True hay False.

• Finite State Machine Coverage: Đưa ra các khái niệm về trạng thái và lịch sử hoạt động của nó. Bao gồm hữu hạn các trạng thái của hệ thống, lưu trữ cách hệ thống đi đến trạng thái đó như thế nào. Có cách xử lý dữ liệu đầu vào (input) khác nhau dựa trên trạng thái hiện tại. Có thể thay đổi trạng thái dựa trên input và sự thay đổi này gọi là transition.

Cách viết Unit test hiệu quả

Arrange, Action, Assert

AAA là một cách tiếp cận chung để viết unit test dễ đọc hơn. Trong bước đầu tiên bạn sắp xếp mọi thứ để kiểm thử. Đó là nơi bạn đặt biến , khởi tạo đối tượng và thực hiện phần còn lại trong quá trình thiết lập càn thiết để chạy kiểm thử. Trong bước này, bạn cũng xác định kết quả mong đợi. Nó mang lại một số lợi thế. Trước hết bạn sẽ buộc phải tìm ra nó trước khi gọi logic đã được kiểm thử. Thứ hai, sẽ thuận tiện hơn khi xem đầu ra dự kiến ngay sau đầu vào và không bị lẫn với phần còn lại của code khi đọc kiểm thử.

Sau đó là Action. Tại đây bạn gọi hàm đã kiểm thử và lưu trữ kết quả của nó. Bước sắp xếp tự nhiên dẫn đến nó và sau khi bạn có kết quả, đã đến lúc xem xét lại.

Bây giờ bạn Assert – khẳng định nếu giả thuyết là chính xác. Đó là bản chất của một bài unit test, vì phần này cuối cùng đang kiểm tra một thứ gì đó. Mục đích là để kiểm tra xem kết quả thu được có khớp với kết quả mong đợi hay không. Các framework unit test có nhiều phương thức xác nhận khác nhau đôi khi được gọi là các matchers dành riêng cho điều đó.

Ngắn gọn

Các chức năng ngắn dễ đọc và dễ hiểu hơn nhiều. Vì chúng ta đang kiểm thử từng đoạn logic, nên các bài kiểm thử không nên dài hơn một vài dòng code.

Tuy nhiên, đôi khi, logic sắp xếp có thể khá phức tạp. Mặc dù đó có thể là dấu hiệu cho thấy có điều gì đó không ổn với code, nhưng logic cấp cao có thể có nhiều phần phụ thuộc yêu cầu khá nhiều code soạn sẵn để khởi tạo mô hình và sơ khai.

Tránh sao chép. Các bài kiểm thử đơn vị không khác nhiều so với code thông thường, vì vậy nguyên tắc DRY (không lặp lại chính bạn) được áp dụng. Đừng quên rằng bạn sẽ phải duy trì chúng trong tương lai – ưu tiên thành phần hơn là kế thừa ở đây. Các lớp cơ sở đó có xu hướng trở thành một đống code được chia sẻ không liên quan.

Đơn giản

Tránh sử dụng logic phức tạp trong các bài kiểm thử. Khi dự án trở nên phức tạp hơn, code chung có thể không còn hoạt động cho tất cả các kịch bản và cũng sẽ phát triển về độ phức tạp để phù hợp với tất cả. Cũng giống như bất kỳ code nào khác, các bài kiểm thử cũng có thể được tái cấu trúc. Bạn sẽ phải tìm một sự cân bằng tốt giữa sự đơn giản và lặp đi lặp lại.

Trong những trường hợp hiếm hoi, các bài kiểm thử có thể trở nên khá phức tạp một cách tự nhiên. Bạn có thể cần các hàm xác nhận tùy chỉnh để kiểm tra kết quả hoặc một framework nhỏ để kiểm thử chức năng tương tự. 

Viết bài kiểm thử trước khi viết code

Đây là phương pháp được gọi là Test Driven Development (TDD) – phát triển theo hướng kiểm thử. Cách tiếp cận này có thể giúp đảm bảo rằng code có thể kiểm thử được, đáp ứng các yêu cầu và dễ bảo trì hơn.

Với TDD, bạn tạo test case trước khi viết code thực tế, sau đó viết code để vượt qua các bài kiểm thử đó. Cách tiếp cận này cũng có thể giúp xác định bất kỳ lỗ hổng nào trong các yêu cầu hoặc logic trươc khi viết bất kỳ code nào. Ngoài ra, TDD có thể giúp các nhóm tránh được chi phí sửa lỗi và lỗi sau này trong chu kỳ phát triển.

Sử dụng Headless Testing

Headless testing là một hình thức thực hiển kiểm thử không có giao diện người dùng hoặc cửa sổ trình duyệt. Cách tiếp cận này có thể hiệu quả và đáng tin cậy hơn so với kiểm thử với giao diện đồ họa, đặc biệt đối với các kiểm thử không yêu cầu tương tác trực quan.

Bạn có thể sử dụng các công cụ như PhantomJS hoặc Headless Chrome để chạy kiểm thử trong môi trường không giao diện. Các công cụ này có thể giúp giảm chi phí bằng giao diện đồ họa và có thể cho phép các bài kiểm thử chạy nhanh hơn và trong một môi trường nhất quán hơn.

Tuy nhiên, điều quan trọng cần lưu ý là không phải tất cả các kiểm thử đều phù hợp .Các kiểm thử liên quan đến tương tác trực quan hoặc hiển thị, chẳng hạn như kiểm thử giao diện người dùng hoặc bố cục trang web, có thể yêu cầu giao diện đồ họa được kiểm thử đúng cách. Do đó, bạn nên cân nhắc cẩn thận kiểm thử nào phù hợp.

Kiểm thử trên tất cả các kịch bản

Điều quan trọng là phải kiểm thử cả kết quả mong đợi và không mong đợi của một hàm hoặc phương thức. Các kiểm thử không tích cực đặc biệt quan trọng để đảm bảo rằng việc xử lý lỗi và các trường hợp ở biên được xử lý chính xác

Các nhà phát triển cũng nên kiểm thử các điều kiện biên, chẳng hạn như giá trị tối thiểu và tối đa của các biến đầu vào. 

Đảm bảo tuân thủ tiêu chuẩn ngành

Liên quan đến việc xác minh rằng ứng dụng đáp ứng các yêu cầu do các quy định hoặc tiêu chuẩn có liên quan đặt ra. Chẳng hạn như HIPAA hoặc PCI-DSS. Kiểm thử tuân thủ có thể giúp đảm bảo rằng ứng dụng an toàn và dữ liệu nhạy cảm được bảo vệ.

Trước tiên, bạn nên xác định các tiêu chuẩn hoặc quy định có liên quan áp dụng cho ứng dụng của mình. Sau đó, bạn nên tạo các test case bao gồm tất cả các yêu cầu liên quan. Ví dụ: nếu ứng dụng được yêu cầu mã hóa tất cả dữ liệu nhạy cảm khi truyền và ở trạng thái nghỉ, thì các test case phải xác minh rằng mã hóa được triển khai chính xác.

Điều quan trọng là phải ghi lại quá trình kiểm thử tuân thủ một cách kỹ lưỡng. Tài liệu này có thể được sử dụng để chứng minh sự tuân thủ với cơ quan quản lý hoặc kiểm toán viên.

Kiểm thử một yêu cầu tại một thời điểm

Đừng kiểm thử toàn bộ phương pháp cùng một lúc. Khi bao gồm các yêu cầu riêng lẻ, code trở nên đơn giản hơn rất nhiều. Bạn có thể chọn một tên cụ thể hơn và bài kiểm thử ít cồng kềnh hơn, dễ đọc hơn và dễ bảo trì hơn.

Nếu các yêu cầu thay đổi, hãy thay đổi các bài kiểm thử tương ứng. Bạn không cần phải xem qua tất cả chúng và kiểm tra những gì bị ảnh hưởng.

Đó cũng là một cách tuyệt vời để biết code nào cần thử kiểm thử ngay từ đầu. Khi viết các bài kiểm thử đảm bảo các yêu cầu của bạn, bạn có thể tìm thấy một số phần code không nhất thiết phải kiểm thử. Nó có thể là một số công cụ nội bộ được code sử dụng đáp ứng trực tiếp các yêu cầu. Trong trường hợp này, nó chỉ đáng để khắc phục sự cố tiếp theo dễ dàng hơn khi kiểm thử yêu cầu không thành công.

Cách thực hiện Unit Test kiểm tra chức năng của phần mềm

Bước 1: Lên kế hoạch cho các bài test

Một hệ thống hay quy trình làm việc muốn mượt và đúng dealine thì bạn cần ấn định rõ từng đầu việc chi tiết theo các hạng mục gắn với từng mốc thời gian. Do đó bạn cần lên một bản kế hoạch kiểm thử Online có sự tương tác giữa các bộ phận, ngắn gọn và dễ nắm bắt.

Bước 2: Tạo kịch bản kiểm thử

Khi bạn muốn test bất cứ cái gì trong phần mềm thì bạn cũng cần nghĩ ra trước mọi biến số có thể và đưa ra kịch bản. Nó giống như hệ thống thể hiện mục đích bạn đang muốn hướng đến là gì?

Bước 3: Tiến hành kiểm thử Unit

Các hạng mục đầu việc ở bước này đều thuộc chuyên môn của Tester gồm: test lệnh và test các mã coder để xem chất lượng, các thay đổi và rủi to trong tương lai gần.

Bước 4: Viết báo cáo tóm tắt

Đòi hỏi bạn cần phải khái quát lại toàn bộ vấn đề, liệt kê các cấu trúc của mỗi Unit và tóm tắt lại các lỗi nếu có. Bên cạnh đó quản trị và lưu trữ toàn bộ dữ liệu của phần mềm sau khi kiểm thử rất quan trọng đối với sự phát triển về sau.

Bước 5: Sửa và hoàn thiện lại code

Sau khi đã test và trả về một bản báo cáo toàn bộ về mỗi Unit, người lập trình sẽ tiến hành sửa và hoàn thiện mã code sao cho phù hợp với kế hoạch ban đầu và chức năng hướng đến sản phẩm.

Trên đây là toàn bộ nội dung chi tiết về Unit Test giúp bạn đọc hiểu rõ hơn về vai trò cùng ưu nhược điểm cùng cách tiến hành. Nếu có bất cứ vấn đề thắc mắc gì cần giải đáp thì bạn hãy để lại bình luận phía bên dưới nhé!

>>> Xem thêm: Test plan là gì? Cách viết test plan hiệu quả trong 8 bước