Làm thế nào để thực hiện unit testing tốt hơn

16/02/2023 01:28

Hôm nay chúng ta sẽ cùng xem xét 4 phương pháp hay nhất về viết các unit testing hiệu quả nhất. Cùng khám phá ngay trong bài viết này bạn nhé

Bạn có muốn nâng cao hiểu biết của mình về các bài kiểm thử đơn vị và học cách tạo các bài kiểm thử đơn vị chất lượng cao một cách có hệ thống không? Sau đó, bạn đang ở đúng nơi.

Hôm nay chúng ta đang xem xét 4 phương pháp hay nhất về viết bài kiểm thử đơn vị, điều này sẽ giúp bạn đảm bảo rằng bạn đang đánh dấu vào tất cả các ô để giữ cho mã của bạn có thể bảo trì và mạnh mẽ trong nhiều năm tới.

1 - Sử dụng đặt tên thử nghiệm mô tả

Các thử nghiệm được tạo cho hai mục đích: chúng ta chạy chúng để đảm bảo mã của chúng ta thực hiện những gì nó dự định thực hiện và chúng ta đọc chúng để hiểu hành vi của ứng dụng.

Điều thứ hai là lý do tại sao chúng ta thường nghe nói về "các bài kiểm thử dưới dạng tài liệu". Nhưng thật dễ dàng để làm cho các bài kiểm thử trở thành tài liệu vô giá trị nếu chúng ta không sử dụng tên và mô tả bài kiểm thử tốt. Khi bạn cấu trúc lại, xem xét hoặc cộng tác trên một đoạn mã, khả năng hiểu nhanh hành vi mà bài kiểm thử đang xác minh là điều quan trọng.

Lấy một tệp thử nghiệm và kiểm thử xem chỉ đọc tên và mô tả của bộ thử nghiệm có cung cấp cho bạn tất cả thông tin bạn cần để hiểu hoạt động của chức năng hay không. Đúng? Bạn có thể di chuyển đến điểm tiếp theo. KHÔNG? Sau đó, bạn có thể cần một số lời khuyên dưới đây.

Thông tin quan trọng nhất mà người đọc bài kiểm thử nên có là hành vi đang được kiểm thử. Chúng ta có thể phân tích hành vi như vậy bằng cách nghĩ về cấu trúc kiểm thử cổ điển “Sắp xếp”, “Hành động”, “Khẳng định”:

Cho xxxxxx
nếu ta làm xxxxxx
ta mong đợi xxxxxx

‍Nếu có thể, thông tin này phải được nêu rõ ràng trong tên hoặc mô tả thử nghiệm, để không có sự mơ hồ về hành vi của chức năng đang được thử nghiệm.

Đây là một cách tiếp cận được phát triển theo định hướng hành vi (BDD) chủ yếu ủng hộ và nó có mục tiêu chính là dễ dàng trao đổi các yêu cầu giữa các bên liên quan kỹ thuật và phi kỹ thuật.

Một số ngôn ngữ và khuôn khổ kiểm thử (ví dụ: Cucumber, Jest, Mocha, ….) đã đón nhận BDD một cách nồng nhiệt và cho phép họ tiếp cận tốt hơn những ngôn ngữ khác bằng cách cung cấp các phương pháp kiểm thử phản ánh ngôn ngữ tự nhiên (“mô tả”, “kiểm thử”, “nó”, “nên”,…) và bằng cách buộc các nhà phát triển đóng khung các bộ kiểm thử và các trường hợp kiểm thử theo một cấu trúc rất có tổ chức.

Chẳng hạn, một thử nghiệm thuộc loại này sẽ có vẻ dễ hiểu đối với bất kỳ ai:

describe(‘Making a withdrawal’,()=>{
		it(‘Should fail if the account is empty’,()=>{
    //…
    });
});

Các ngôn ngữ khác, chẳng hạn như Java, không cung cấp các công cụ rõ ràng như vậy để giải thích dài dòng về hành vi kiểm thử. Do đó, cần phải tạo một tên thử nghiệm tổng hợp nhưng mang tính biểu cảm sẽ thực hiện cùng một công việc.

Dưới đây là một vài cách tiếp cận phổ biến, có thể được điều chỉnh tùy theo nhu cầu của bạn:

ClassName_MethodName_Scenario_Expectation
ClassName_MethodName_Should_Expectation_When_Scenario
ClassName_MethodName_When_Scenario_Should_Expectation

2 - Đảm bảo các bài kiểm thử đơn vị của bạn đáng tin cậy

Khi chúng ta nói rằng một bài kiểm thử đơn vị phải đáng tin cậy, chúng ta muốn nói rằng nó chỉ thất bại khi chức năng không hoạt động và khi nó vượt qua, nó đảm bảo rằng chức năng đó đang hoạt động bình thường. Để đạt được mức độ tự tin này trong các bài kiểm thử của mình, bạn nên lưu tâm đến ba lĩnh vực:

‍Thiếu sự phụ thuộc

Các nhà phát triển thường nghĩ rằng họ đang viết bài kiểm thử đơn vị, nhưng thực ra họ đang viết bài kiểm thử tích hợp được ngụy trang dưới dạng bài kiểm thử đơn vị. Điều này là do chúng sẽ bao gồm một số thành phần phụ thuộc (chẳng hạn như thời gian, cơ sở dữ liệu, API hoặc lệnh gọi đến một chức năng cục bộ khác), đôi khi có thể tạo ra kết quả hoặc lỗi không mong muốn do các yếu tố bên ngoài (hãy nghĩ đến một API đạt đến số lượng tối đa số kết nối mỗi phút chẳng hạn), và do đó ảnh hưởng đến độ tin cậy của bài kiểm thử của bạn. Việc loại bỏ các phụ thuộc này thông qua mô phỏng sẽ cải thiện đáng kể độ tin cậy của bài kiểm thử của bạn.
Kích thước của đơn vị được thử nghiệm
Hầu hết thời gian, một chức năng hoặc phương pháp là kích thước phạm vi thích hợp cho thử nghiệm đơn vị của bạn, nhưng bạn phải luôn đánh giá trường hợp này theo từng trường hợp. Đôi khi, việc chọn một đơn vị quá nhỏ không có đủ logic có thể dẫn đến việc kiểm thử không có tác động rõ rệt đến khả năng bảo trì mã của bạn. Những lần khác, các chức năng quá phức tạp để có thể kiểm thử bằng một bài kiểm thử đơn vị duy nhất và thay vào đó, nên chia thành các đơn vị nhỏ hơn trước khi tiến hành kiểm thử.
Phạm vi của các kịch bản
Điều cần thiết là phải đảm bảo rằng phạm vi của các kịch bản có trong một thử nghiệm bao gồm tất cả các khả năng hành vi cho một chức năng. Điều này còn được gọi là “phạm vi trường hợp sử dụng” và nó mang lại cho chúng ta niềm tin rằng mỗi khi thử nghiệm vượt qua, điều đó có nghĩa là chức năng của chúng ta hoạt động như mong đợi. Đôi khi nó có thể dẫn đến các công thức thử nghiệm hơi dư thừa, nhưng điều quan trọng là phải đảm bảo rằng tất cả các tình huống đặc tả đều được tính đến.
Chẳng hạn, ta có thể có ba tình huống sau:

nếu độ tuổi của người dùng bằng hoặc trên 18, người dùng có thể truy cập trang web
nếu tuổi người dùng dưới 18, họ sẽ thấy thông báo lỗi
Nếu độ tuổi người dùng dưới 18, họ không thể truy cập trang web

Hai kịch bản dưới cùng tương tự nhau, nhưng không giống nhau. Chúng kiểm thử các hành vi hơi khác nhau và bạn nên kiểm thử hai kịch bản cùng một lúc.

>>> Đọc thêm: 6 mẹo để tạo Unit Test hiệu quả

3 - Đừng chỉ dựa vào phạm vi bảo hiểm

‍Nhiều công ty sử dụng các mục tiêu bao phủ mã làm ngôi sao duy nhất của họ để theo dõi các bài kiểm thử đơn vị của họ và nhiều nhà phát triển không quá ám ảnh với các bài kiểm thử đơn vị khá hài lòng với điều này. Nhưng nếu bạn thực sự muốn tăng chất lượng và độ bền của mã của mình, thì bạn nên thực hiện một cách tiếp cận định tính hơn và coi mức độ phù hợp của mã là một trong những chỉ báo có sẵn cho bạn chứ không phải là chỉ báo duy nhất.

>>>> Đọc thêm: Unit Test là gì? bạn biết gì về thuật ngữ Unit Test trong IT

Phạm vi mã 100% (nếu bạn có thể đạt được điều đó!) không có nghĩa là mã của bạn không có lỗi. Nó cho biết có bao nhiêu dòng đơn vị hoặc cơ sở mã của bạn được bao phủ, nhưng nó khiến bạn không biết kịch bản kiểm thử nào mà bạn có thể đã bỏ lỡ cho đến nay và do đó bạn quên kiểm thử hành vi nào.

Điều này đặc biệt đúng khi các kịch bản không hoàn toàn tương ứng với các nhánh hoặc dòng khác nhau trong mã của bạn. Vì điều này, chúng ta thường khuyên các nhà phát triển nên tin tưởng vào mức độ bao phủ mã thấp như một cảnh báo tốt về cơ sở mã chưa được kiểm thử, nhưng không tin vào mức độ bao phủ mã cao như một tín hiệu về tính toàn diện của thử nghiệm.

4 - Giả một cách thận trọng

Ở trên, chúng ta đã thảo luận về tầm quan trọng của một thử nghiệm độc lập - nghĩa là đơn vị được cách ly với các đơn vị hoặc phần phụ thuộc khác. Điều này đạt được thông qua chế nhạo.

Mocking cho phép chúng ta loại bỏ tất cả các phụ thuộc khỏi một chức năng vì mục đích thử nghiệm của chúng ta và do đó kiểm thử nó như một đơn vị biệt lập và do đó, đây là một công cụ mạnh mẽ đáng gờm. Tuy nhiên, chúng ta nên lưu tâm và sử dụng chế giễu một cách thận trọng. Có hai lý do chính cho việc này:

‍Mã tốt không được ghép nối nhiều

Về bản chất, mã tốt nên có càng ít khớp nối và phụ thuộc càng cần thiết. Đây là những gì giữ cho nó có thể đọc được, có thể bảo trì và mạnh mẽ. Nếu chúng ta thấy mình phải giả lập 5 phương thức khác nhau trong cùng một chức năng, thì đây có thể là dấu hiệu cho thấy mã của chúng ta quá phức tạp và sẽ được hưởng lợi từ việc tái cấu trúc một chút. Sau đó, cách tiếp cận tốt nhất thay vì nhảy thẳng vào viết bài kiểm thử đơn vị, sẽ là xem xét lại thiết kế của chức năng và dịch vụ được đề cập để làm cho đơn vị của chúng ta đơn giản hơn theo thiết kế.
Mocking làm cho việc tái cấu trúc trở nên khó khăn hơn
Khi chúng ta giới thiệu một bản mô phỏng trong thử nghiệm của mình, điều đó có nghĩa là chúng ta không chỉ kiểm thử hành vi bên ngoài của mã (tức là cho đầu vào XI nhận được đầu ra Y), mà chúng ta còn kiểm thử hoạt động bên trong của chính mã đó, bằng cách cho biết những mô-đun nào khác đang được sử dụng, những đầu vào nào được truyền cho chúng, chúng được gọi bao nhiêu lần, chúng sẽ trả về cái gì, v.v. Điều này có nghĩa là nếu tại một thời điểm nào đó, chúng ta muốn thay đổi thiết kế mã của mình và loại bỏ sự phụ thuộc vào một mô-đun, thì toàn bộ thử nghiệm sẽ phải được sửa đổi. Nói tóm lại, chi phí thay đổi trở nên lớn hơn nhiều.

Vì lý do này, bất cứ khi nào bạn cần mô phỏng, hãy suy nghĩ kỹ xem có bất kỳ đơn giản hóa thiết kế nào bạn có thể áp dụng cho mã của mình hay không và xem xét liệu tất cả các mô-đun có thực sự cần được mô phỏng hay không và ở mức độ nào. Ví dụ, trong một số trường hợp, bạn có thể phát hiện ra rằng sử dụng một hình nộm thay vì một bản mô phỏng đầy đủ (sơ khai và gián điệp) là đủ.

5 - Làm cho bài kiểm thử của bạn chạy nhanh

‍

Khung thử nghiệm Mocha tuyên bố rằng bất kỳ thử nghiệm nào mất hơn 75 mili giây để chạy đều bị coi là chậm. Điều này có vẻ cực đoan, nhưng trong thực tế, các bài kiểm thử chậm gây nguy hiểm cho tính hữu dụng và hiệu quả của chính chúng.

Các nhà phát triển có xu hướng không chạy các bài kiểm thử chậm thường xuyên như khi họ chạy các bài kiểm thử nhanh, và do đó, họ giảm khả năng phát hiện lỗi và hồi quy trước người dùng. Bạn sẽ không muốn giảm niềm tin vào mã của mình vì chiến lược thử nghiệm đơn vị không cảnh báo bạn về các lỗi tiềm ẩn, phải không?

Để giữ cho các bài kiểm thử của bạn chạy nhanh, đây là ba câu thần chú cần tuân theo:

giữ chúng đơn giản
giữ cho họ độc lập
luôn chế nhạo các phụ thuộc bên ngoài.

Bạn có thể nhận thấy rằng đây là tất cả các điểm xuất phát từ các phần trước của bài viết này. Chà - đó là bởi vì chúng ta chỉ đang tham gia vào các dấu chấm. Tốc độ của bài kiểm thử là một cách hay để xác minh xem bài kiểm thử có tốt hay không. kiểm thử chậm thường là dấu hiệu cho thấy có điều gì đó không ổn.

‍

Nếu bạn làm theo tất cả các phương pháp hay ở trên, bạn sẽ đi đúng hướng để tạo các bài kiểm thử đơn vị hoàn hảo. Hãy nhớ rằng bạn luôn nên viết các bài kiểm thử ngay sau khi viết mã, vì việc thay đổi tác vụ là kẻ thù của sự kỹ lưỡng.