Là bài kiểm tra đơn vị thực sự được sử dụng như tài liệu?

Tôi không thể đếm số lần tôi đọc các câu lệnh trong 'các bài kiểm tra đơn vị là một nguồn tài liệu rất quan trọng của mã được kiểm tra'. Tôi không phủ nhận họ là sự thật.

Nhưng cá nhân tôi chưa bao giờ thấy mình sử dụng chúng làm tài liệu. Đối với các khung công tác điển hình mà tôi sử dụng, các khai báo phương thức ghi lại hành vi của chúng và đó là tất cả những gì tôi cần. Và tôi giả sử đơn vị kiểm tra sao lưu mọi thứ được nêu trong tài liệu đó, cộng với có khả năng là một số nội dung khác, do đó, một mặt nó sao chép phần trích dẫn trong khi mặt khác nó có thể thêm một số thứ không liên quan.

Vì vậy, câu hỏi là: khi nào các bài kiểm tra đơn vị được sử dụng làm tài liệu? Khi các ý kiến ​​không bao gồm tất cả mọi thứ? Do nhà phát triển mở rộng nguồn? Và những gì họ phơi bày có thể hữu ích và có liên quan mà bản thân tài liệu không thể phơi bày?

Chúng KHÔNG phải là Tài liệu tham khảo của ABSOLUTE

Lưu ý rằng rất nhiều điều sau đây cũng áp dụng cho các nhận xét, vì chúng có thể không đồng bộ với mã, như các thử nghiệm (mặc dù nó ít được thi hành hơn).

Vì vậy, cuối cùng, cách tốt nhất để hiểu mã là có mã làm việc dễ đọc .

^{Nếu có thể và không viết các phần mã cấp thấp có dây cứng hoặc các điều kiện đặc biệt khó khăn thì tài liệu bổ sung sẽ rất quan trọng.}

• Các xét nghiệm có thể không đầy đủ:
  • API đã thay đổi và chưa được thử nghiệm,
  • Người viết mã đã viết các bài kiểm tra cho các phương pháp dễ nhất để kiểm tra trước thay vì các phương thức quan trọng nhất để kiểm tra, và sau đó không có thời gian để hoàn thành.
• Các xét nghiệm có thể bị lỗi thời.
• Các thử nghiệm có thể được ngắn mạch theo những cách không rõ ràng và không thực sự được thực hiện.

NHƯNG họ VẪN là một bổ sung tài liệu hữu ích

Tuy nhiên, khi nghi ngờ về những gì một lớp cụ thể làm, đặc biệt là nếu các bình luận khá dài, tối nghĩa và thiếu (bạn biết loại ...), tôi nhanh chóng thử tìm (các) lớp kiểm tra của nó và kiểm tra:

• những gì họ thực sự cố gắng kiểm tra (đưa ra gợi ý về các mẩu tin quan trọng nhất, ngoại trừ nếu nhà phát triển đã thực hiện lỗi được đề cập ở trên chỉ thực hiện các thử nghiệm "dễ dàng"),
• và nếu có trường hợp góc.

Ngoài ra, nếu được viết bằng cách sử dụng kiểu BDD , chúng sẽ đưa ra một định nghĩa khá tốt về hợp đồng của lớp . Mở IDE của bạn (hoặc sử dụng grep) để chỉ xem tên phương thức và tada: bạn có một danh sách các hành vi.

Regressions và Bugs cũng cần các bài kiểm tra

Ngoài ra, đó là một cách thực hành tốt để viết các bài kiểm tra cho hồi quy và cho các báo cáo lỗi: bạn sửa một cái gì đó, bạn viết một bài kiểm tra để tái tạo trường hợp. Khi nhìn lại chúng, đó là một cách tốt để tìm báo cáo lỗi có liên quan và tất cả các chi tiết về một vấn đề cũ chẳng hạn.

Tôi muốn nói rằng chúng là một bổ sung tốt cho tài liệu thực và ít nhất là một tài nguyên có giá trị trong vấn đề này. Đó là một công cụ tốt, nếu được sử dụng đúng cách. Nếu bạn bắt đầu thử nghiệm sớm trong dự án của mình và biến nó thành thói quen, thì COULD là một tài liệu tham khảo rất tốt. Trên một dự án hiện có với thói quen mã hóa xấu đã làm hôi thối cơ sở mã, hãy cẩn thận xử lý chúng.

Một cách giải thích là các bài kiểm tra đơn vị là "tài liệu thực thi". Bạn có thể chạy các bài kiểm tra đơn vị dựa trên mã và nó sẽ cho bạn biết liệu nó có còn hoạt động như khi bài kiểm tra được viết để vượt qua hay không. Theo cách đó, đơn vị kiểm tra "tài liệu" chức năng của hệ thống tại một thời điểm nào đó, theo cách có thể thực hiện được.

Mặt khác, tôi cũng hiếm khi thực sự đọc mã kiểm tra đơn vị là "tài liệu" để hiểu chức năng. Một bài kiểm tra đơn vị quá cục bộ, cụ thể và trừu tượng theo cách có thể cho bạn biết nhiều về hệ thống thực tế đằng sau lớp đang được kiểm tra.

Nếu theo tài liệu, ý bạn là tôi muốn tìm hiểu cách thức hoạt động của mã thì các kiểm thử đơn vị là những ví dụ hoàn hảo về cách các đơn vị mã hoạt động trong cả hai trường hợp dự kiến , trường hợp cạnh và lỗi (còn gọi là lỗi ). Ngoài ra, các thử nghiệm của bạn có thể được tạo trước khi mã được viết, do đó, dựa trên những gì mã cần làm theo quan điểm kinh doanh / yêu cầu.

Họ đang thay thế tài liệu? Không.

Chúng có phải là một phụ lục hữu ích cho tài liệu không? Vâng.

Tôi thấy các bài kiểm tra đơn vị là:

• một cách để chứng minh tài liệu là chính xác (giả sử tài liệu phù hợp với việc thực hiện api).
• một cách để demo cho nhà phát triển cách sử dụng một tính năng cụ thể; đồ đạc kiểm tra đơn vị / bản thân bài kiểm tra đơn vị thường đủ nhỏ để người ta có thể nhanh chóng học hỏi từ nó.
• và rõ ràng để phát hiện bất kỳ lỗi hồi quy.

Đối với một số mở rộng, chúng có thể được coi là một bổ sung cho một tài liệu hiện có nhưng không phải là tài liệu.

Tôi sẽ trả lời câu hỏi của bạn bằng cách hỏi bạn khác.

Tần suất khi làm việc với API / thói quen mới, bạn đã từ chối trợ giúp để tìm kiếm một ví dụ mã về thứ bạn đang cố gắng sử dụng? Không thể chuyển sang google để tìm kiếm trực tuyến các mẫu mã?

Đó là chính xác khi bạn sẽ sử dụng các bài kiểm tra đơn vị làm tài liệu.

• Trong thực tế, các bài kiểm tra đơn vị có thể nghiêm ngặt hơn một chút so với các ví dụ mã thông thường, bởi vì bạn nên có nhiều bài kiểm tra (ví dụ).
• Hy vọng bài kiểm tra đơn vị của bạn minh họa việc sử dụng đúng . Ví dụ: Chúng hiển thị rõ ràng tất cả các phụ thuộc thiết yếu thông qua các đối tượng bình thường hoặc các đối tượng giả. (Nếu không, chúng không phải là bài kiểm tra đơn vị đặc biệt tốt.)
• LƯU Ý: Nếu nhận xét hoặc "tài liệu thông thường" của bạn cung cấp các ví dụ về mã, bạn thực sự vi phạm các nguyên tắc DRY. Và những ví dụ mã đó có thể dễ dàng trở thành không chính xác theo thời gian, trong khi đó có ít khả năng điều đó hơn với các bài kiểm tra đơn vị được thực hiện thường xuyên.
• Nếu các bài kiểm tra đơn vị kỹ lưỡng (thường là nếu lớn ), thì họ nên cung cấp thêm thông tin:
  • Tất cả các trường hợp cạnh được biết minh họa rõ ràng.
  • Tất cả các ngoại lệ dự kiến ​​có thể được ném.
  • Tất cả các lỗi được tìm thấy trước đây (điều này có thể hữu ích hơn khi mở rộng đơn vị được kiểm tra so với khi viết một ứng dụng khách mới cho đơn vị).
  • Tất cả các quy tắc kinh doanh cơ bản liên quan đến các đơn vị. (nếu có)

Tôi nghi ngờ có khá nhiều lý do kiểm tra đơn vị không có xu hướng được sử dụng làm tài liệu mặc dù chúng có thể là một bổ sung tuyệt vời cho tài liệu truyền thống hơn:

• Tôi sẽ mạo hiểm đề nghị rằng thường thì các bài kiểm tra không đủ để viết cho mục đích này. Các câu trả lời khác đã ám chỉ đến các bài kiểm tra đó là:
  • Chưa hoàn thiện.
  • Gây nhầm lẫn. . )
  • Đã lỗi thời. (thông thường các bài kiểm tra sẽ thất bại khi chúng trở nên lỗi thời, nhưng điều này không phải lúc nào cũng đúng).
• Thường có rất nhiều ví dụ về việc sử dụng đã có sẵn trong mã sản xuất bất cứ khi nào có nhu cầu về một ví dụ phát sinh.
• Đơn vị được thử nghiệm được viết rất tốt (tự ghi lại tài liệu) đến mức các phương thức không cần ví dụ. Tôi ước!
• Theo kinh nghiệm của tôi với tư cách là một lập trình viên, chúng tôi có xu hướng khá nhạy bén để nhảy vào cuối sâu và RTFM vào thứ ba tới ...
• Tài liệu và ý kiến ​​vi phạm nguyên tắc DRY.

Các bài kiểm tra Đơn vị TL và DR và ​​các nhận xét API là bổ sung - một số điều được mô tả tốt nhất trong mã và những điều khác trong văn xuôi.

Các thử nghiệm đơn vị chủ yếu hữu ích để ghi lại các trường hợp đặc biệt và các điều kiện cạnh khó (và cồng kềnh) để mô tả trong các nhận xét API. Ngoài ra, các nhận xét API thường được hướng đến những người muốn sử dụng API.

Nếu bạn muốn sửa đổi mã, thông thường bạn cần biết nhiều hơn và một số điều đó rất khó để đưa vào nhận xét (và những bình luận này sẽ nhanh chóng bị hỏng). Trong trường hợp đó, một bài kiểm tra đơn vị cũng hoạt động như tài liệu.

Một ví dụ: Bạn có một phương thức m (a, b)thực hiện một phép tính nhất định. Do các yêu cầu tương thích ngược, nó phải nhập các trường hợp đặc biệt của a=0và a=-1, nhưng chỉ khi blà NULL. Đưa nó vào một bình luận là phức tạp, dài dòng và có khả năng trở nên cũ kỹ nếu yêu cầu này bị loại bỏ sau đó.

Nếu bạn thực hiện một số bài kiểm tra đơn vị kiểm tra hành vi của m(0, NULL), m(-1, x)bạn sẽ nhận được một số lợi ích:

• Mô tả hành vi đúng là rõ ràng, hiểu lầm được giảm
• Mọi người không thể bỏ qua yêu cầu khi họ thay đổi mã, không giống như một nhận xét