Làm thế nào tôi nên kiểm tra mã TEST của mình?


22

Một trong số ít những điều mà hầu hết các nhà phát triển phần mềm đồng ý là bạn không nên dựa vào mã để hoạt động chính xác trừ khi bạn kiểm tra nó. Nếu bạn không kiểm tra nó, nó có thể có các lỗi ẩn chỉ khiến bạn phải làm việc nhiều hơn.

Tôi hiểu cách kiểm tra mã thông thường của mình, nhưng tôi nên kiểm tra mã kiểm tra của mình như thế nào để đảm bảo mã có thể tìm và báo cáo lỗi một cách hiệu quả khi chúng có mặt? Cá nhân tôi đã đủ ngu ngốc để viết các trường hợp kiểm tra sai lầm sẽ vượt qua khi họ không nên có, do đó đánh bại mục đích kiểm tra viết của tôi ngay từ đầu. May mắn thay, tôi đã tìm thấy và sửa lỗi kịp thời, nhưng theo câu thần chú thử nghiệm, có vẻ như không có bộ kiểm thử nào được hoàn thành nếu không có bộ kiểm tra riêng để đảm bảo nó hoạt động.

Dường như với tôi, cách tốt nhất để làm điều này là đảm bảo kiểm tra không thành công cho mã lỗi. * Nếu tôi dành 2 phút xen kẽ thêm lỗi vào mã và đảm bảo nó thất bại, tôi nên có mức độ tin cậy chấp nhận được các bài kiểm tra 'làm việc'. Điều này đưa tôi đến câu hỏi thứ hai của tôi: các cách tốt để giới thiệu các lỗi để đảm bảo rằng chúng bị bắt bởi các trường hợp thử nghiệm? Tôi có nên bình luận ngẫu nhiên các câu lệnh, đảm bảo nhánh sai của một lệnh if-elseđược chạy bằng cách phủ định điều kiện của nó và thay đổi thứ tự thực thi mã với các tác dụng phụ, v.v., cho đến khi tôi hài lòng các bài kiểm tra của mình sẽ nắm bắt được hầu hếtlỗi thường gặp? Làm thế nào để các nhà phát triển chuyên nghiệp xác nhận rằng các thử nghiệm của họ thực sự làm những gì họ phải làm? Họ chỉ cho rằng các bài kiểm tra hoạt động, hay họ cũng dành thời gian để kiểm tra chúng? Nếu vậy làm thế nào để họ kiểm tra các bài kiểm tra?

Tôi không đề nghị mọi người nên dành quá nhiều thời gian để kiểm tra các bài kiểm tra của họ và sau đó kiểm tra các bài kiểm tra cho các bài kiểm tra của họ rằng họ không bao giờ thực sự viết mã thực sự, nhưng tôi đã làm những điều ngu ngốc đến mức tôi cảm thấy mình có thể hưởng lợi từ một chút về 'thử nghiệm meta', và tò mò về cách tốt nhất để thực hiện nó. : D

* Tôi có thể kiểm tra xem thử nghiệm có vượt qua khi kiểm tra mã 'không có lỗi' hay không, nhưng sử dụng mã làm thông số kỹ thuật cho thử nghiệm có vẻ khá ngược ...


Âm thanh như bạn không tự tin trong bài kiểm tra đơn vị của bạn - rất có thể là do bạn thiếu nhiều kinh nghiệm trong bài kiểm tra viết? Trong trường hợp đó, sẽ là không hợp lý khi viết thêm các bài kiểm tra và mong đợi một kết quả khác. Chỉ cần tiếp tục làm những gì bạn đang làm, kỹ lưỡng nhất có thể (kiểm tra thất bại cũng như thành công) và ngay sau đó các bài kiểm tra đơn vị của bạn sẽ bắt đầu tự trả tiền - và sự tự tin của bạn sẽ tăng lên.
MattDavey


Trước khi sử dụng nhiều công cụ hơn, hãy sử dụng các công cụ thực tế của bạn tốt hơn . Viết ít bài kiểm tra, nhưng bài kiểm tra viết hiệu quả hơn và tốt hơn. Bạn không thể tin vào những điều bạn không hiểu.
Steve Chamaillard

Câu trả lời:


16

Luồng tiêu chuẩn cho TDD là:

  1. Viết một bài kiểm tra thất bại. (Đỏ)
  2. Thực hiện thay đổi mã nhỏ nhất khiến nó vượt qua (Màu xanh lá cây)
  3. Refactor (Giữ cho nó xanh)

Thử nghiệm cho các thử nghiệm của bạn trong trường hợp này là bước 1 - đảm bảo rằng thử nghiệm thất bại trước khi bạn thực hiện bất kỳ thay đổi mã nào.

Một thử nghiệm khác mà tôi thích là liệu bạn có thể xóa một số mã và thực hiện lại nó theo một cách khác hay không, và các thử nghiệm của bạn thất bại sau khi xóa nhưng hoạt động với một thuật toán khác.

Như với tất cả mọi thứ, không có viên đạn ma thuật. Việc quên viết một bài kiểm tra bắt buộc cũng dễ dàng cho nhà phát triển làm như quên viết mã. Ít nhất nếu bạn đang làm cả hai, bạn có gấp đôi cơ hội để khám phá ra thiếu sót của mình.


4
Sổ sách kế toán kép: Các bài kiểm tra đơn vị kiểm tra mã sản xuất và ngược lại. Chúng là hai cách khác nhau để nêu cùng một vấn đề. Giống như trong sổ sách kế toán kép, nơi bạn ghi lại các giao dịch của mình theo hai cách khác nhau và cả hai phải có cùng một tổng số.
EricSchaefer

Câu hỏi là về vấn đề khi bước 2 làm cho thử nghiệm có màu xanh mặc dù mã vẫn còn lỗi. Ví dụ đơn giản: bạn có một hàm phải trả về một con trỏ tới một đối tượng danh sách không trống. Thử nghiệm của bạn kiểm tra xem con trỏ có nullbị lỗi ở bước 1. Bạn thực hiện thay đổi mã nhỏ nhất khiến nó vượt qua bằng cách trả về một danh sách trống. Bài kiểm tra hiện "xanh" vì bạn có hai lỗi.
Christian Hackl

@ChristianHackl ở giai đoạn phát triển đó là một triển khai hoàn hảo! Bạn phải thêm một (hoặc nhiều) bài kiểm tra thất bại lúc đầu để xác định thêm hành vi dự kiến. Sau đó, bạn thực hiện nó, làm cho các thử nghiệm này màu xanh lá cây.
Andy

@Andy: Quan tâm đến việc xây dựng làm thế nào đây là một triển khai hoàn hảo khi tôi gặp một lỗi cả trong mã và trong bài kiểm tra, và một điều khiến tôi không chú ý đến cái khác? (Lỗi trong mã là một danh sách trống được trả về và lỗi trong kiểm tra là tôi kiểm tra nullvà không để trống.)
Christian Hackl

@ChristianHackl bạn đúng theo kiểm tra trống. Điều đó, thực sự, nên được thực hiện trong một bài kiểm tra là tốt. Khi bạn dịch các yêu cầu của mình sang các bài kiểm tra, từng bước một, sẽ có rất ít chỗ cho các lỗi. Ngoại trừ những người khi bạn không dính vào thông số kỹ thuật (như xem một tấm séc không trống).
Andy

9

Một cách tiếp cận là Kiểm tra đột biến , sử dụng một công cụ như Jester :

Jester thực hiện một số thay đổi đối với mã của bạn, chạy thử nghiệm của bạn và nếu các thử nghiệm vượt qua, Jester sẽ hiển thị một thông báo cho biết nó đã thay đổi


4

Xét nghiệm cho xét nghiệm? Đừng đi con đường đó. Sau đó, có lẽ bạn sẽ cần các bài kiểm tra để kiểm tra, và sau đó kiểm tra các bài kiểm tra để kiểm tra ... bạn dừng lại ở đâu?

Luồng thử nghiệm thông thường diễn ra như thế này và là một nhà phát triển, bạn sẽ dành phần lớn thời gian của mình cho các điểm 1-3:

  1. Bài kiểm tra đơn vị
  2. Kiểm tra tích hợp
  3. Hệ thống / tự động khác
  4. QA / người thử nghiệm

Nếu tôi dành 2 phút xen kẽ thêm lỗi vào mã (...)

Mã của bạn cuối cùng sẽ "phát triển" các lỗi của chính nó, đừng lãng phí thời gian giới thiệu chúng bằng tay. Chưa kể, một điều bạn biết về trả trước có thực sự là một lỗi không? Lỗi sẽ đến, tôi sẽ không lo lắng về điều đó.

Tôi có nên bình luận ngẫu nhiên các câu lệnh không, đảm bảo nhánh sai của if-if được chạy bằng cách phủ định điều kiện của nó (...)

Đây thực sự là một cách tiếp cận khả thi để xác minh xem bạn có thực sự kiểm tra những gì bạn nghĩ bạn làm hay không. Tôi không nghĩ nó luôn tốt như vậy vì nó gặp phải vấn đề tương tự như "kiểm tra để kiểm tra ...": khi nào bạn ngừng thay đổi mã biết mã bạn đang kiểm tra 100% hoạt động?

Bạn cũng nên nhớ về lời khuyên lập trình viên thực dụng cổ điển mọi lúc - bạn sẽ không cần nó . Hãy nhanh nhẹn, viết các bài kiểm tra và mã cho các lỗi thực tế, thay vào đó là những giả thuyết có thể hoặc không thể xuất hiện.


3
Tôi không lo lắng về việc mã của tôi phát triển các lỗi của chính nó, tôi lo lắng về các thử nghiệm của mình bắt được chúng khi chúng xảy ra. Nếu các bài kiểm tra của tôi bị lỗi, họ sẽ không thực hiện công việc của mình và tôi nghĩ rằng tôi đã thoát khỏi một loại lỗi nhất định khi chúng thực sự tồn tại, chỉ khiến công việc của tôi khó khăn hơn vì tôi đang xem kết quả kiểm tra không chính xác (vượt qua khi họ nên thất bại).
Gordon Gustafson

@CrazyJugglerDrummer: các bài kiểm tra của bạn sẽ không bắt được tất cả các lỗi đó là điều chắc chắn. Họ không phục vụ mục đích đó - đây là nơi QA xuất hiện. Nếu họ làm như vậy, điều đó có nghĩa là phần mềm không có lỗi, trừ khi thay đổi mã nguồn, điều mà tôi chưa từng thấy.
km

3

Bằng cách xây dựng, mã chức năng và mã kiểm tra được kiểm tra so với mã kia. Một vấn đề vẫn còn: trường hợp lỗi chế độ phổ biến, khi một lỗi trong mã chức năng bị ẩn bởi một lỗi trong mã kiểm tra. TDD không tránh khỏi hiệu ứng này. Đây là lý do tại sao kiểm tra thường được thực hiện ở nhiều cấp độ bởi những người khác nhau để giảm xác suất này.


0

Bạn kiểm tra bài kiểm tra đơn vị của bạn một lần khi bạn viết nó, trong trình gỡ lỗi. Sau đó, bạn để nó một mình và quên nó. Không có vấn đề ở đây.

Xem xét điều này. Mục đích của một bài kiểm tra đơn vị là gì? Nó thông báo cho bạn khi bất kỳ thay đổi nào trong số nhiều thay đổi bạn sẽ thực hiện trong chương trình chính của mình vô tình thay đổi logic trong chương trình đó. Bạn muốn có điều đó bởi vì bạn biết rằng bất kỳ thay đổi nào cũng có khả năng phá vỡ một cái gì đó. Đó chính xác là lý do tại sao không có vấn đề gì nếu bạn không kiểm tra bài kiểm tra của mình: bạn không gây rối với bài kiểm tra của mình cho đến khi bạn cố tình thay đổi logic chương trình của mình (điều này sẽ yêu cầu bạn xem lại bài kiểm tra và kiểm tra lại một lần nữa), vì vậy kiểm tra không có khả năng phá vỡ vô tình.


-2

một thử nghiệm đột biến để đánh giá và đo lường sự phù hợp và chất lượng của thử nghiệm.

Chúng ta có thể sử dụng điều này để tự đánh giá "bài kiểm tra".

Tóm lại, Chúng tôi có thể đánh giá thử nghiệm của mình (ví dụ TestA) bằng cách thử nghiệm TestA có thể tìm thấy sự khác biệt giữa mã và mã đột biến của nó (mã rất giống nhau nhưng hơi khác với mã gốc).

Nếu TestA không thể tìm thấy sự khác biệt giữa mã và mã đột biến của nó, điều đó có nghĩa là TestA có các quy định quá thô sơ để kiểm tra mã gốc.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.