Có hợp lý không khi viết bài kiểm tra đơn vị vì chúng có xu hướng được nhận xét sau hoặc vì kiểm tra tích hợp có giá trị hơn?

Tôi đã thảo luận về kiểm tra đơn vị / tích hợp với một đồng nghiệp, và anh ấy đã đưa ra một trường hợp thú vị chống lại việc viết các bài kiểm tra đơn vị. Tôi là người đề xuất thử nghiệm đơn vị lớn (chủ yếu là JUnit), nhưng rất thích nghe người khác thực hiện, vì anh ta đã đưa ra một số điểm thú vị.

Tổng hợp điểm của mình:

• Khi xảy ra thay đổi mã chính (bộ POJO mới, tái cấu trúc ứng dụng chính, v.v.), các kiểm tra đơn vị có xu hướng được nhận xét thay vì làm lại.
• Thời gian tốt hơn dành cho các bài kiểm tra tích hợp bao gồm các trường hợp sử dụng, điều này làm cho các bài kiểm tra phạm vi nhỏ hơn ít / không quan trọng.

Suy nghĩ về điều này? Tôi vẫn đang thử nghiệm đơn vị (vì tôi luôn thấy nó tạo ra mã được cải thiện), mặc dù các thử nghiệm tích hợp nghe có vẻ ít có giá trị.

Tôi có xu hướng bên cạnh bạn của bạn bởi vì tất cả quá thường xuyên, các bài kiểm tra đơn vị đang kiểm tra những điều sai .

Bài kiểm tra đơn vị không phải là xấu. Nhưng họ thường kiểm tra các chi tiết thực hiện hơn là luồng đầu vào / đầu ra. Bạn kết thúc với các bài kiểm tra hoàn toàn vô nghĩa khi điều này xảy ra. Quy tắc riêng của tôi là một bài kiểm tra đơn vị tốt cho bạn biết rằng bạn vừa phá vỡ một cái gì đó; một bài kiểm tra đơn vị xấu chỉ cho bạn biết rằng bạn vừa thay đổi một cái gì đó.

Một ví dụ ngoài đỉnh đầu của tôi là một bài kiểm tra đã được đưa vào WordPress vài năm trước. Các chức năng đang được kiểm tra xoay quanh các bộ lọc gọi nhau và các kiểm tra đang xác minh rằng các cuộc gọi lại sau đó sẽ được gọi theo đúng thứ tự. Nhưng thay vì (a) chạy chuỗi để xác minh rằng các cuộc gọi lại được gọi theo thứ tự dự kiến, các thử nghiệm tập trung vào (b) đọc một số trạng thái nội bộ được cho là không nên tiếp xúc với. Thay đổi phần bên trong và (b) chuyển sang màu đỏ; trong khi (a) chỉ chuyển sang màu đỏ nếu các thay đổi bên trong phá vỡ kết quả mong đợi trong khi thực hiện. (b) rõ ràng là một thử nghiệm vô nghĩa theo quan điểm của tôi.

Nếu bạn có một lớp học đó cho thấy nhiều một vài phương pháp để thế giới bên ngoài, những điều đúng để thử nghiệm trong quan điểm của tôi là những phương pháp sau chỉ . Nếu bạn cũng kiểm tra logic bên trong, cuối cùng bạn có thể phơi bày logic bên trong ra thế giới bên ngoài, sử dụng các phương pháp kiểm tra phức tạp hoặc với một loạt các bài kiểm tra đơn vị luôn luôn phá vỡ bất cứ khi nào bạn muốn thay đổi bất cứ điều gì.

Với tất cả những gì đã nói, tôi sẽ ngạc nhiên nếu bạn của bạn rất quan trọng về các bài kiểm tra đơn vị như bạn dường như đề xuất. Thay vào đó tôi sẽ tập hợp anh ấy thực dụng. Đó là, ông quan sát thấy rằng các bài kiểm tra đơn vị được viết hầu hết là vô nghĩa trong thực tế. Trích dẫn: "các bài kiểm tra đơn vị có xu hướng được nhận xét hơn là làm lại". Đối với tôi có một thông điệp ngầm trong đó - nếu họ có xu hướng cần làm lại thì đó là vì họ có xu hướng hút. Giả sử như vậy, đề xuất thứ hai như sau: các nhà phát triển sẽ lãng phí ít thời gian hơn để viết mã khó bị sai hơn - tức là kiểm tra tích hợp.

Như vậy không phải là về một người tốt hơn hay xấu hơn. Chỉ là một điều dễ dàng hơn rất nhiều để có được sai lầm, và thực sự rất thường xuyên sai trong thực tế.

Khi thay đổi mã lớn xảy ra, các bài kiểm tra đơn vị có xu hướng được nhận xét thay vì làm lại.

Với một nhóm các lập trình viên cao bồi vô kỷ luật, những người nghĩ rằng tất cả các bài kiểm tra nhận được "màu xanh lá cây" được thực hiện khi bạn nhận xét tất cả các bài kiểm tra hiện có: tất nhiên. Làm lại các bài kiểm tra đơn vị có cùng số lượng kỷ luật như viết chúng ngay từ đầu, vì vậy điều bạn phải làm ở đây là "định nghĩa hoàn thành" của nhóm bạn.

Thời gian tốt hơn dành cho các bài kiểm tra tích hợp bao gồm các trường hợp sử dụng làm cho các bài kiểm tra phạm vi nhỏ hơn ít / không quan trọng.

Điều đó không hoàn toàn sai cũng không hoàn toàn đúng. Nỗ lực viết các bài kiểm tra tích hợp hữu ích phụ thuộc rất nhiều vào loại phần mềm bạn đang viết. Nếu bạn có một phần mềm trong đó các bài kiểm tra tích hợp có thể dễ dàng được viết như các bài kiểm tra đơn vị, chúng vẫn chạy nhanh và cung cấp cho bạn phạm vi bảo hiểm tốt về mã của bạn, thì đồng nghiệp của bạn có một điểm. Nhưng đối với nhiều hệ thống tôi đã thấy ba điểm này không thể dễ dàng được thực hiện bằng các bài kiểm tra tích hợp, đó là lý do tại sao bạn nên cố gắng để có các bài kiểm tra đơn vị.

Tôi không biết rằng tôi chấp nhận lập luận của đồng nghiệp.

1. Nếu các bài kiểm tra đơn vị được nhận xét, đó là vì ai đó lười biếng. Đó không phải là lỗi của bài kiểm tra đơn vị. Và nếu bạn bắt đầu sử dụng lười biếng như một cái cớ, bạn có thể tranh luận chống lại hầu hết mọi thực hành đòi hỏi một chút nỗ lực.
2. Nếu bạn làm đúng, các bài kiểm tra đơn vị sẽ không mất nhiều thời gian. Họ không ngăn bạn làm việc quan trọng hơn. Nếu tất cả chúng ta đồng ý rằng việc sửa mã bị hỏng là quan trọng hơn bất kỳ điều gì khác, một bài kiểm tra đơn vị là khá quan trọng. Đó là một cách dễ dàng để kiểm tra điều kiện bài. Không có nó, làm thế nào để bạn biết bạn đã đáp ứng các điều kiện đảm bảo bài? Và nếu bạn không có, mã của bạn bị hỏng.

Có những lý lẽ khác, hấp dẫn hơn chống lại các bài kiểm tra đơn vị. Vâng, không chính xác chống lại họ. Bắt đầu với thiệt hại thiết kế do thử nghiệm của DHH . Anh ấy là một nhà văn vui vẻ, vì vậy hãy đọc nó. Những gì tôi đã lấy từ nó:

Nếu bạn thực hiện thay đổi thiết kế lớn để phù hợp với các bài kiểm tra đơn vị của bạn, chúng có thể cản trở các mục tiêu khác trong dự án của bạn. Nếu có thể, hãy hỏi một người vô tư cách tiếp cận nào dễ thực hiện hơn. Nếu mã khó kiểm tra của bạn khó hiểu, bạn có thể mất tất cả các lợi ích bạn có được từ thử nghiệm đơn vị. Chi phí nhận thức của quá nhiều sự trừu tượng làm bạn chậm lại và làm cho những sai lầm rò rỉ dễ dàng hơn. Đừng giảm giá nó.

Nếu bạn muốn có được sắc thái và triết lý, có rất nhiều tài nguyên tuyệt vời:

• Thử nghiệm của Ian Bicking được coi là có hại (Thử nghiệm không đủ. Các thử nghiệm không làm cho mã đẹp.)
• Bảo hiểm mã ngày càng tăng của Dan Manges có thể có hại (Sử dụng phạm vi bảo hiểm mã làm số liệu không cho bạn biết nếu bạn đang làm gì hữu ích.)
• Sau đó, có bất kỳ đối số tốt cho việc không viết bài kiểm tra đơn vị? [đã đóng] từ Stack Overflow. (Tự tin quá mức, chi phí không được công nhận, không tìm thấy các lỗi ngấm ngầm, không phải là sự thay thế cho mã đẹp [giống như Bicking], v.v ...)

Khi xảy ra thay đổi mã chính (bộ POJO mới, tái cấu trúc ứng dụng chính, v.v.), các kiểm tra đơn vị có xu hướng được nhận xét thay vì làm lại.

Đừng làm vậy. Nếu bạn tìm thấy ai đó làm điều đó, hãy giết họ và đảm bảo họ không sinh sản, vì con cái của họ có thể thừa hưởng gen khiếm khuyết đó. Chìa khóa như tôi thấy khi xem các chương trình truyền hình CSI là phân tán rất nhiều mẫu DNA sai lệch ở khắp mọi nơi. Bằng cách này, bạn làm ô nhiễm hiện trường vụ án với rất nhiều tiếng ồn, do tính chất tốn kém và tốn thời gian của xét nghiệm DNA, khả năng họ sẽ ghim nó xuống với bạn là rất thấp.

kiểm tra đơn vị có xu hướng được nhận xét hơn là làm lại.

Tại thời điểm đó, quy trình xem xét mã cho biết "hãy sửa các bài kiểm tra đơn vị" và đây không còn là vấn đề nữa :-) Nếu quy trình xem xét mã của bạn không bắt được loại lỗ hổng lớn này trong mã đã gửi, thì đó là vấn đề.

Khi xảy ra thay đổi mã chính (bộ POJO mới, tái cấu trúc ứng dụng chính, v.v.), các kiểm tra đơn vị có xu hướng được nhận xét thay vì làm lại.

Tôi luôn cố gắng giữ cấu trúc lại và thay đổi chức năng riêng biệt. Khi tôi cần làm cả hai, tôi thường cam kết tái cấu trúc trước.

Khi tái cấu trúc mã mà không thay đổi chức năng, các kiểm tra đơn vị hiện có được cho là giúp đảm bảo rằng tái cấu trúc không vô tình phá vỡ chức năng. Vì vậy, đối với một cam kết như vậy, tôi sẽ coi việc vô hiệu hóa hoặc loại bỏ các bài kiểm tra đơn vị là một dấu hiệu cảnh báo chính. Bất kỳ nhà phát triển nào làm điều đó nên được yêu cầu không làm như vậy khi mã đang được xem xét.

Có thể các thay đổi không thay đổi chức năng vẫn khiến các bài kiểm tra đơn vị bị lỗi do các bài kiểm tra đơn vị thiếu sót. Nếu bạn hiểu mã bạn đang thay đổi thì nguyên nhân của các lỗi kiểm tra đơn vị như vậy thường ngay lập tức rõ ràng và dễ khắc phục.

Ví dụ: nếu một hàm có ba đối số, một thử nghiệm đơn vị bao gồm sự tương tác giữa hai đối số đầu tiên cho hàm có thể không được quan tâm để cung cấp một giá trị hợp lệ cho đối số thứ ba. Lỗ hổng này trong bài kiểm tra đơn vị có thể bị lộ bởi việc tái cấu trúc mã đã kiểm tra, nhưng rất dễ sửa nếu bạn hiểu mã phải làm gì và kiểm tra đơn vị đang kiểm tra.

Khi thay đổi chức năng hiện có, thông thường cũng cần phải thay đổi một số bài kiểm tra đơn vị. Trong trường hợp này, kiểm tra đơn vị giúp đảm bảo rằng mã của bạn thay đổi chức năng như dự định và không có tác dụng phụ ngoài ý muốn.

Khi sửa lỗi hoặc thêm chức năng mới, người ta thường cần thêm nhiều bài kiểm tra đơn vị. Đối với những người này có thể hữu ích để cam kết kiểm tra đơn vị trước và cam kết sửa lỗi hoặc chức năng mới sau. Điều đó giúp dễ dàng xác minh rằng các thử nghiệm đơn vị mới không vượt qua với mã cũ hơn nhưng vượt qua với mã mới hơn. Cách tiếp cận này không hoàn toàn không có nhược điểm, do đó, cũng tồn tại các đối số có lợi cho việc cam kết cả hai bài kiểm tra đơn vị mới và cập nhật mã đồng thời.

Thời gian tốt hơn dành cho các bài kiểm tra tích hợp bao gồm các trường hợp sử dụng, điều này làm cho các bài kiểm tra phạm vi nhỏ hơn ít / không quan trọng.

Có một số yếu tố của sự thật này. Nếu bạn có thể nhận được phạm vi bảo hiểm của các lớp thấp hơn của ngăn xếp phần mềm với các thử nghiệm nhắm mục tiêu vào các lớp cao hơn của ngăn xếp phần mềm, các thử nghiệm của bạn có thể hữu ích hơn khi tái cấu trúc mã.

Tôi không nghĩ rằng bạn sẽ tìm thấy một thỏa thuận về sự khác biệt chính xác giữa một bài kiểm tra đơn vị và một bài kiểm tra tích hợp. Và tôi sẽ không lo lắng nếu bạn có một trường hợp thử nghiệm mà một nhà phát triển gọi thử nghiệm đơn vị và một cuộc gọi khác là thử nghiệm tích hợp, miễn là họ có thể đồng ý rằng đó là một trường hợp thử nghiệm hữu ích.

Các thử nghiệm tích hợp được thực hiện để kiểm tra xem hệ thống có hoạt động như mong muốn hay không, vốn luôn có giá trị kinh doanh. Các bài kiểm tra đơn vị không phải lúc nào cũng làm điều đó. Các bài kiểm tra đơn vị có thể là kiểm tra mã chết, ví dụ.

Có một triết lý kiểm tra nói rằng bất kỳ bài kiểm tra nào không cung cấp cho bạn thông tin đều là sự lãng phí. Khi một đoạn mã không được thực hiện, các bài kiểm tra đơn vị của nó luôn luôn (hoặc gần như luôn luôn) sẽ có màu xanh, cung cấp cho bạn ít hoặc không có thông tin.

Mọi phương pháp kiểm tra sẽ không đầy đủ. Ngay cả khi bạn nhận được bảo hiểm 100% theo một số liệu, bạn vẫn không trải qua gần như mọi bộ dữ liệu đầu vào có thể. Vì vậy, đừng nghĩ thử nghiệm đơn vị là ma thuật.

Tôi thường thấy yêu cầu kiểm tra đơn vị cải thiện mã của bạn. Theo tôi, những cải tiến mà các bài kiểm tra đơn vị mang lại cho mã đang buộc những người không quen sử dụng nó phải chia mã của họ thành những phần nhỏ, có nhiều yếu tố. Nếu bạn đã quen với việc thiết kế mã của mình thành các phần nhỏ, có yếu tố thông thường, bạn có thể thấy rằng bạn không cần các bài kiểm tra đơn vị để buộc bạn phải làm điều đó nữa.

Tùy thuộc vào mức độ kiểm tra đơn vị của bạn và chương trình của bạn lớn như thế nào, bạn có thể kết thúc với một lượng lớn bài kiểm tra đơn vị. Nếu vậy, những thay đổi lớn trở nên khó khăn hơn. Nếu một thay đổi lớn gây ra nhiều thử nghiệm đơn vị thất bại, bạn có thể từ chối thực hiện thay đổi, thực hiện nhiều công việc để khắc phục rất nhiều thử nghiệm hoặc ném các thử nghiệm đi. Không có sự lựa chọn nào là lý tưởng.

Kiểm tra đơn vị là một công cụ trong hộp công cụ. Họ ở đó để phục vụ bạn chứ không phải cách khác. Hãy chắc chắn để thoát khỏi chúng ít nhất là nhiều như bạn đặt vào.

Bài kiểm tra đơn vị chắc chắn không phải là viên đạn bạc mà một số người đề xướng tuyên bố. Nhưng nhìn chung họ có tỷ lệ chi phí / lợi ích rất tích cực. Họ sẽ không làm cho mã của bạn "tốt hơn", có thể mô đun hơn. "tốt hơn" có rất nhiều yếu tố hơn so với "khả năng kiểm tra" ngụ ý. Nhưng họ sẽ đảm bảo nó hoạt động trong tất cả các trường hợp và cách sử dụng mà bạn nghĩ đến, và sẽ loại bỏ hầu hết các lỗi của bạn (có thể là những lỗi nhỏ hơn).

Lợi ích lớn nhất của các bài kiểm tra đơn vị là chúng làm cho mã của bạn linh hoạt hơn và có khả năng phục hồi để thay đổi. Bạn có thể cấu trúc lại hoặc thêm các tính năng và khá tự tin rằng bạn đã không phá vỡ bất cứ điều gì. Điều này một mình làm cho chúng đáng giá cho hầu hết các dự án.

Đề cập đến các điểm được thực hiện bởi bạn của bạn:

1. Nếu việc thêm POJO phá vỡ các bài kiểm tra đơn vị của bạn thì có lẽ chúng được viết rất tệ. POJO thường là ngôn ngữ bạn đang sử dụng để nói về tên miền của bạn và các vấn đề bạn đang giải quyết, thay đổi chúng rõ ràng có nghĩa là toàn bộ logic kinh doanh của bạn và có lẽ mã trình bày phải thay đổi. Bạn không thể mong đợi những gì đảm bảo những phần đó trong chương trình của bạn sẽ không thay đổi ...

2. Khiếu nại rằng các bài kiểm tra Đơn vị là xấu, bởi vì mọi người nhận xét chúng, giống như phàn nàn dây an toàn là xấu vì mọi người không đeo chúng. Nếu một người bình luận ra mã kiểm tra và phá vỡ một cái gì đó, anh ta sẽ kết thúc một cuộc trò chuyện rất nghiêm túc và khó chịu với sếp của mình ...

3. Kiểm tra tích hợp là vượt trội hơn nhiều so với kiểm tra đơn vị. không có câu hỏi đặc biệt nếu bạn đang thử nghiệm một sản phẩm. Nhưng viết các bài kiểm tra tích hợp tốt, toàn diện, điều đó sẽ mang lại cho bạn cùng một giá trị, độ bao phủ và đảm bảo tính chính xác mà bài kiểm tra đơn vị mang lại cho bạn, là vô cùng khó.

Tôi chỉ có thể nghĩ về một đối số chống lại các bài kiểm tra đơn vị, và nó khá yếu.

Các bài kiểm tra đơn vị cho thấy phần lớn giá trị của chúng khi bạn cấu trúc lại hoặc thay đổi mã ở giai đoạn sau. Bạn thấy giảm đáng kể thời gian cần thiết để thêm các tính năng và đảm bảo bạn không bị hỏng bất cứ thứ gì.

Tuy nhiên: Có một chi phí (nhỏ) trong thời gian viết bài kiểm tra ở nơi đầu tiên mặc dù.

Do đó: Nếu một dự án đủ ngắn và không yêu cầu bảo trì / cập nhật liên tục, có thể chi phí viết bài kiểm tra vượt xa lợi ích của họ.