Chất lượng của mã trong các bài kiểm tra đơn vị?

Khi viết bài kiểm tra đơn vị, có đáng để dành thêm thời gian để làm cho mã có chất lượng tốt và dễ đọc không?

Khi viết bài kiểm tra tôi thường phá vỡ Luật Demeter , để viết nhanh hơn và để tránh sử dụng quá nhiều biến số. Về mặt kỹ thuật, các bài kiểm tra đơn vị không được sử dụng lại trực tiếp - chúng bị ràng buộc chặt chẽ với mã nên tôi không thấy bất kỳ lý do nào để dành nhiều thời gian cho chúng; họ chỉ cần có chức năng.

Bạn chắc chắn nên thực hiện tương tự nếu không chăm sóc tốt hơn các bài kiểm tra đơn vị của bạn hơn mã sản xuất của bạn về chất lượng và khả năng đọc. Các bài kiểm tra đơn vị thường là điều đầu tiên bạn nhìn vào khi cố gắng nắm bắt những gì một đoạn mã nào đó và người đọc nên nhanh chóng hiểu những gì đang bị đe dọa khi xem xét nghiệm. Các thử nghiệm đơn vị cũng có xu hướng thay đổi rất nhiều và sẽ phá vỡ rất nhiều nếu thiết kế của chúng không mạnh mẽ, điều này vô hiệu hóa các lợi ích của việc thử nghiệm.

Vi phạm Luật Demeter chắc chắn là một vấn đề trong các bài kiểm tra đơn vị của bạn vì lý do đó cũng như 2 điều khác xuất hiện trong tâm trí của tôi:

• Nếu các bài kiểm tra của bạn vi phạm Luật Demeter trong các phần Sắp xếp hoặc Đạo luật của họ , thì đó có thể là dấu hiệu cho thấy mã sản xuất của bạn cũng vậy, vì các bài kiểm tra đơn vị của bạn chỉ là một người tiêu dùng mã khác của bạn và có thể sẽ gọi và vận hành lớp được kiểm tra giống nhau cách mà bất kỳ mã sản xuất khác sẽ làm.

• Nếu các thử nghiệm của bạn phá vỡ Luật Demeter trong các phần Khẳng định của chúng (tức là bạn xác minh giá trị của một thứ gì đó được lồng sâu trong biểu đồ phụ thuộc của đối tượng được kiểm tra), thì đó có thể là những thử nghiệm tích hợp thực sự thay vì thử nghiệm đơn vị. Nói cách khác, nếu trong TestA bạn khẳng định rằng ABCD bằng với một cái gì đó, thì có thể bạn đang thực sự thử nghiệm D và A thay vì chỉ A.

Nhân tiện, khi bạn nói

Tôi rất thường xuyên phá vỡ Luật Demeter, vì viết nhanh hơn và không sử dụng quá nhiều biến số.

bạn nên biết rằng viết

var grab = myDependency.Grab;
var something = grab.Something;
var very = something.Very;

very.Deep();

thực sự không có gì tốt hơn Demeter khôn ngoan hơn

myDependency.Grab.Something.Very.Deep();

nếu đó là những gì bạn muốn nói

Hoàn toàn đáng để dành thời gian viết mã chất lượng tốt cho các bài kiểm tra đơn vị:

• Họ sẽ yêu cầu bảo trì như bất kỳ mã nào khác.
• Kiểm tra đơn vị là một trong những nguồn tài liệu tốt nhất cho hệ thống của bạn và được cho là hình thức đáng tin cậy nhất. Họ nên thực sự hiển thị:
  • Ý định: "hành vi dự kiến ​​là gì?".
  • Cách sử dụng: "Tôi phải sử dụng API này như thế nào?".
• Họ sẽ yêu cầu gỡ lỗi như bất kỳ mã nào khác.

Một yếu tố ủng hộ cách tiếp cận đặc biệt hơn một chút là các bài kiểm tra đơn vị của bạn sẽ không bao giờ là API công khai, do đó bạn không cần phải lo lắng về giao diện / v.v. bạn đang phơi bày

Vâng, nó quan trọng. Có một số lý do tại sao các bài kiểm tra đơn vị nên được giữ theo một tiêu chuẩn tương đương như các mã khác:

• Mỗi bài kiểm tra đơn vị cũng phục vụ như là tài liệu cho người được kiểm tra. Khi các bài kiểm tra là toàn diện và bao gồm càng nhiều trường hợp cạnh và điều kiện lỗi càng tốt, chúng thường có thể thay thế tài liệu nhận xét của một lớp hoặc hàm. Chúng cũng có thể đóng vai trò là điểm khởi đầu cho những người mới sử dụng cơ sở mã.

• Kiểm tra đơn vị có thể là lỗi, quá. Và lỗi được hiển thị nhiều hơn khi mã được viết tốt.

• Nếu, vì một số lý do, sau này bạn cần phải tách một mô-đun, có lẽ bạn cũng cần phải chia ra các bài kiểm tra đơn vị của nó. Điều này dễ dàng hơn nếu các bài kiểm tra được viết sao cho chúng có sự phụ thuộc dễ dàng nhận thấy.

Điều đó nói rằng, luôn luôn có câu hỏi về thực tiễn. Tùy thuộc vào ngôn ngữ và bản chất của mã của bạn, có thể khó viết các bài kiểm tra đơn vị "sạch" mà không mất nhiều thời gian hơn cho các bài kiểm tra so với mã mà họ phải kiểm tra. Trong trường hợp đó, tôi thường quay lại thử nghiệm những thứ dễ dàng, nhanh chóng và chức năng quan trọng nhất, mà không phải lo lắng quá nhiều về phạm vi bảo hiểm hoàn chỉnh. Bất cứ khi nào một lỗi phát sinh vào một thời điểm sau đó, tôi viết một bài kiểm tra cho nó và kiểm tra xem tôi có thể cấu trúc lại bài kiểm tra mới và các bài kiểm tra hiện có để làm cho chúng đẹp hơn không.

nếu bạn không thể đọc một số ít nhất và tìm hiểu xem nó đang kiểm tra gì vào lần tiếp theo thì nó sẽ mất gấp đôi thời gian gỡ lỗi (một lần để tìm hiểu thử nghiệm là gì và một lần để sửa mã mà nó đang kiểm tra)

trung thực không đáng tin cậy nên có một kết quả mong đợi; làm thủ tục; có được kết quả thực tế; kiểm tra dự kiến ​​đối với loại cấu trúc thực tế dễ viết và dễ hiểu

Mã kiểm tra sẽ nhận được nhiều tình yêu như mã sản xuất của bạn. Để dễ đọc, thậm chí có thể nhiều hơn. Nếu bất kỳ ai khác ngoài bạn (bao gồm cả bạn hai tuần sau khi để lại mã) được cho là hiểu những gì đang xảy ra, thì bạn nên làm cho mã của mình trở nên rõ nét.

Điều này có nghĩa là:

• Trích xuất xây dựng dữ liệu thử nghiệm vào các lớp xây dựng.
• Trích xuất các xác nhận đa dạng vào các phương pháp khẳng định riêng biệt.
• Hãy rất chính xác trong việc đặt tên của bạn. Assert.That(x4, Is.EqualTo(y16*2*SOME_VALUE), ASS_ERR_TXT_56)làm cho rất ít ý nghĩa cho hầu hết độc giả.

Được thực hiện đến cùng cực, các bài kiểm tra có thể được viết để chúng gần như dễ đọc VÀ dễ hiểu như văn xuôi. Người kiểm tra cực đoan có thể nói rằng một bài kiểm tra đơn vị dài hơn 10 dòng là một bài kiểm tra tồi.

Lý do thực tế quan trọng nhất là mỗi khi bạn thay đổi mã, bạn thay đổi các bài kiểm tra đơn vị. Và nếu bạn đang làm TDD, trước tiên bạn sẽ thay đổi bài kiểm tra đơn vị.

Làm một trong những điều này trong bài kiểm tra của bạn:

• Mã trùng lặp
• Giảm khả năng đọc
• Khớp nối chặt chẽ
• Khớp nối tạm thời
• Độ phức tạp chu kỳ cao (rất nhiều phụ thuộc)

Và bạn đang làm rất nhiều việc khi cần thay đổi.

Hãy đối xử với các bài kiểm tra của bạn như bạn đề xuất và cuối cùng bạn sẽ hối hận. Thậm chí bạn sẽ có thể đi đến kết luận sai lầm rằng "TDD không hoạt động".

Nó phụ thuộc vào việc các bài kiểm tra đơn vị này là "tạm thời" hay không. Nếu

1. Kiểm tra sẽ được sử dụng thường xuyên;

2. Các nhà phát triển phải làm việc với các bài kiểm tra đơn vị được viết bởi các nhà phát triển khác;

3. Hầu hết các thử nghiệm được thực hiện bằng các thử nghiệm đơn vị

sau đó các bài kiểm tra nên được viết đúng. Trong trường hợp có lỗi trong bản thân bài kiểm tra, sẽ rất khó để tìm ra lỗi và sửa nó, đặc biệt nếu một thời gian đã trôi qua kể từ khi bài kiểm tra được viết.

Mặt khác, nếu các thử nghiệm này chỉ được sử dụng bởi chính các nhà phát triển, thì tôi nghĩ rằng nó ổn. Nhưng vẫn nên viết mã 'dễ đọc' hơn. Như ratchet freak đã nói, bạn sẽ dành nhiều thời gian hơn để sửa bài kiểm tra của mình hơn là bạn sẽ dành cho việc viết chúng đúng cách.