Kiểm tra đơn vị có ý nghĩa gì đối với bạn?

Question

G'day,

Tôi đang làm việc với một nhóm các nhà phát triển nước ngoài đã sử dụng thử nghiệm đơn vị từ khá lỏng lẻo.

Tài liệu QA của họ nói về việc viết các bài kiểm tra đơn vị và sau đó thực hiện kiểm tra đơn vị của hệ thống.

Điều này không phù hợp với cách giải thích của tôi về thử nghiệm đơn vị nào.

Tôi thường được dùng để kiểm tra đơn vị là một thử nghiệm hoặc bộ kiểm tra đang được sử dụng để thực hiện một lớp đơn, thường là hộp đen. Các lớp học được kiểm tra có thể yêu cầu các lớp khác được bao gồm bởi việc thực hiện nhưng nói chung nó là một lớp duy nhất đang được thực hiện bởi các bài kiểm tra đơn vị (s).

Sau đó, bạn có hệ thống chức năng kiểm tra, thử nghiệm hội nhập, kiểm tra chấp nhận vv

Tôi muốn biết điều này là một chút pedantic trên một phần của tôi? Hay đây là những gì bạn nghĩ đến khi đề cập đến các bài kiểm tra đơn vị và kiểm thử đơn vị?

Chỉnh sửa: Rob Wells. Tôi cần phải làm rõ rằng việc tiếp cận thử nghiệm như vậy từ góc độ hộp đen chỉ là một khía cạnh. Khi sử dụng các đối tượng giả để xác minh các hành vi nội bộ, bạn thực sự đang thử nghiệm từ góc độ hộp màu trắng vì bạn biết những gì bạn muốn xảy ra bên trong hộp.

Answer 1

Tôi cố gắng thực hiện các kiểm tra đơn vị để chỉ thử nghiệm một phương pháp duy nhất. và tôi cố gắng đánh bại các lớp "giả" cho các lớp và phương thức phụ thuộc được sử dụng bởi phương pháp tôi đang kiểm tra ... ... để việc thực thi mã trong phương thức đó không thực sự gọi mã theo các phương pháp khác kiểm tra đơn vị không được coi là "Thử nghiệm" (Có các thử nghiệm đơn vị khác cho các phương pháp đó) Bằng cách này, sự thất bại của việc kiểm tra đơn vị cho thấy sự thất bại của phương pháp mà thử nghiệm đơn vị đang thử nghiệm ...

Các lớp mô phỏng được thiết kế để "mô phỏng" giao diện và hành vi của các lớp phụ thuộc để phương pháp mà tôi đang thử nghiệm có thể gọi cho chúng và chúng sẽ hoạt động theo tiêu chuẩn, được xác định rõ theo các yêu cầu hệ thống. Để làm cho phương thức này hoạt động, các cuộc gọi đến các lớp phụ thuộc như vậy và các phương thức của chúng phải được thực hiện trên một giao diện được xác định rõ ràng, để quá trình "tester" có thể "tiêm" phiên bản Mock của lớp phụ thuộc vào lớp đang được kiểm tra thay vào đó của phiên bản sản xuất thực tế .... Điều này giống như một mẫu thiết kế chung được gọi là "Nghiện phụ thuộc" hoặc "Đảo ngược kiểm soát" (IOC)

Có một số công cụ của bên thứ ba trên thị trường để giúp bạn triển khai loại mẫu này. Một trong những tôi đã nghe nói về được gọi là "Rhino-Mock" hoặc một cái gì đó như thế ...

Edit: Rob Wells. @Charles. Cám ơn vì cái này. Tôi đã quên sử dụng các đối tượng giả để thay thế hoàn toàn bằng cách sử dụng các lớp khác ngoại trừ các lớp đang được kiểm tra.

Một vài điều khác mà tôi đã nhớ đến sau khi bạn nhắc đến các đối tượng giả là:

• họ có thể được sử dụng để mô phỏng lỗi được trả về bởi các lớp học bao gồm.
• chúng có thể được sử dụng để tăng ngoại lệ cụ thể để kiểm tra xử lý ngoại lệ trong lớp đang được kiểm tra.
• chúng có thể được sử dụng để mô phỏng các mục có chi phí thiết lập cao, ví dụ: một kết thúc SQL DB lớn.
• chúng có thể được sử dụng để xác minh nội dung của yêu cầu đến.

Để biết thêm thông tin, có một cái nhìn vào tờ giấy Martin Fowler được gọi là "Mocks Aren't Stubs" và Bài báo Pragmatic Programmers của "Mock Objects"

Answer 2

Kiểm tra đơn vị thường được các nhà phát triển sử dụng để kiểm tra các phần mã bị cô lập. Chúng bao gồm các trường hợp biên giới, các trường hợp lỗi và các trường hợp thông thường. Chúng được thiết kế để chứng minh tính chính xác của một đoạn mã giới hạn. Nếu tất cả các bài kiểm tra đơn vị của bạn vượt qua, thì bạn đã chứng minh rằng các đoạn mã bị cô lập của bạn làm những gì họ phải làm.

Khi bạn thực hiện kiểm tra tích hợp, bạn đang xem xét các trường hợp đầu cuối, để xem liệu tất cả các phân đoạn đã vượt qua thử nghiệm đơn vị có hoạt động cùng nhau hay không. Kiểm tra chức năng kiểm tra xem mã có đáp ứng các yêu cầu như được chỉ định hay không. Kiểm tra chấp nhận được thực hiện bởi người dùng cuối để xem liệu họ có chấp nhận sản phẩm cuối cùng hay không.

Answer 3

Tôi đã nghe về các kỹ thuật trong đó nhiều thử nghiệm đơn vị được thực hiện trước và phát triển được thực hiện xung quanh chúng. Ai đó vừa nhận xét rằng đây là "Kiểm tra Phát triển theo hướng" - TDD (Cảm ơn Elie).

Nhưng nếu đây là một hoạt động ngoài khơi có thể sẽ tính phí cho bạn nhiều hơn bởi vì họ dành thời gian làm các bài kiểm tra đơn vị này - thì tôi sẽ cẩn thận. Nhận ý kiến ​​thứ hai từ một người nào đó, trải nghiệm với các bài kiểm tra đơn vị, những người sẽ xác minh rằng họ đang thực sự làm như họ nói.

Từ hiểu biết của tôi, kiểm tra đơn vị sẽ thêm một chút thời gian cho bất kỳ dự án phát triển nào, nhưng tất nhiên có thể cung cấp một số kiểm soát chất lượng. Tuy nhiên, đây là loại kiểm soát chất lượng mà tôi muốn với một dự án trong nhà. Điều này có thể chỉ là một cái gì đó công ty ra nước ngoài ném ra có để cung cấp cho bạn một mờ ấm.

Answer 4

Wikipedia dường như đề xuất rằng thử nghiệm đơn vị là về thử nghiệm số lượng mã nhỏ nhất sẽ là một phương pháp trên lớp trong trường hợp lập trình OO.

Một số có thể có một thuật ngữ chung hơn về ý nghĩa của các bài kiểm tra đơn vị, trong đó một số có thể nghĩ về một số xét nghiệm tích hợp làm bài kiểm tra đơn vị trong đó đơn vị là hỗn hợp các thành phần.

Answer 5

Đây gần như là sự lặp lại của câu hỏi "What is a 'Unit'?".

"Đơn vị" có thể được xác định linh hoạt. Nếu tài liệu của họ không có định nghĩa về "đơn vị", bạn sẽ cần phải làm rõ điều đó.

Có thể họ nghĩ đơn vị là một tập hợp mã lớn. Đó không phải là định nghĩa mong muốn nhất.

Trong khi tôi đồng ý rằng bạn có nhiều lớp kiểm tra (đơn vị, mô-đun, gói, ứng dụng), tôi cũng nghĩ rằng phần lớn việc này có thể được thực hiện bằng các công cụ kiểm tra đơn vị. Dẫn đến "đơn vị là gì?" các câu hỏi luôn xuất hiện.

Đơn vị phụ thuộc vào ngữ cảnh. Đối với nhà phát triển cá nhân, đơn vị phải là Lớp. Đôi khi, nó cũng sẽ có nghĩa là mô-đun hoặc gói.

Tuy nhiên, đối với một nhóm, đơn vị của họ có thể là một gói hoặc một ứng dụng hoàn chỉnh.

Answer 6

Điều gì chúng ta nghĩ là gì? Vấn đề ở đây là sự bất hạnh của bạn với các điều khoản mà họ sử dụng trong tài liệu. Tại sao bạn không thảo luận với họ?

Answer 7

Không có lý do tại sao các bài kiểm tra đơn vị không thể mở rộng nhiều lớp, hoặc thậm chí các mô-đun con, miễn là bài kiểm tra chỉ xử lý một hoạt động kinh doanh nhất quán. Hãy suy nghĩ về "calculateWage", một phương pháp của một BO sử dụng các chiến lược khác nhau để tính toán mức lương của một người. Đó là một bài kiểm tra đơn vị theo ý kiến ​​của tôi.

Answer 8

Có sự khác biệt giữa quy trình bạn sử dụng để kiểm tra và công nghệ được sử dụng để hỗ trợ nó. Các khuôn khổ khác nhau được sử dụng để kiểm thử đơn vị thường rất linh hoạt và có thể được sử dụng để thử nghiệm các đơn vị mã nhỏ, các đơn vị lớn và thậm chí thử nghiệm toàn bộ các quy trình. Sự linh hoạt này có thể dẫn đến sự nhầm lẫn.

Khuyến nghị của tôi là bất kỳ phương pháp hoặc quy trình cụ thể nào mà bạn áp dụng mà bạn tách riêng Kiểm tra Đơn vị khác nhau thành các hội đồng hoặc mô-đun riêng biệt. Việc sắp xếp chính xác tùy thuộc vào mã của bạn và tổ chức của công ty bạn.

Hiệu ứng tích lũy của việc sử dụng khung Kiểm tra đơn vị là phần lớn việc kiểm tra mã được tự động hóa. Được thông qua một cách chính xác các nhà phát triển có thể đánh giá những thay đổi đối với mã code tốt hơn với việc thực hiện một quy trình Q & đầy đủ. Đối với Q & Một quá trình tự nó làm cho thời gian của họ hiệu quả hơn vì chất lượng của mã ra khỏi phát triển nên cao hơn.

Hiểu nó không phải là câu trả lời cho tất cả các vấn đề chất lượng, nó chỉ là một công cụ hữu ích như công cụ khác mà bạn sử dụng.

Answer 9

có chế độ xem truyền thống là http://en.wikipedia.org/wiki/Software_testing như một phần của http://en.wikipedia.org/wiki/Software_engineering. nhưng tôi thích ý tưởng của một bài kiểm tra đơn vị nhanh: một bài kiểm tra là một bài kiểm tra đơn vị nhanh nếu nó đủ nhanh để các lập trình viên luôn luôn chạy.

Answer 10

Mười năm trước, trước khi sử dụng hiện tại "kiểm tra đơn vị" làm thử nghiệm được viết bằng mã, chỉ định tương tự đã được áp dụng cho các kiểm tra thủ công. Tôi đã làm việc cho một công ty phát triển phần mềm với một quy trình phát triển phần mềm rất chính thức. Chúng tôi đã phải viết "kiểm tra đơn vị" trước khi viết bất kỳ mã nào. Trong thời đại đó, các bài kiểm tra đơn vị được viết trong một tài liệu văn bản (như trong Word). Họ đã mô tả các bước chính xác mà người dùng đã theo dõi trong việc sử dụng ứng dụng. Ví dụ: họ mô tả đầu vào chính xác để nhập trên trang để thiết lập khách hàng mới. Hoặc, người dùng đã tìm kiếm một sản phẩm cụ thể và thấy rằng thông tin được hiển thị khớp với tài liệu thử nghiệm. Vì vậy, thử nghiệm là một kịch bản mà người thử nghiệm đã theo dõi, nơi họ cũng ghi lại kết quả. Khi hóa thân mới của thử nghiệm đơn vị xuất hiện, nó đã gây nhầm lẫn trong một thời gian cố gắng tìm hiểu xem chúng có nghĩa là các xét nghiệm cũ, con người hay các xét nghiệm mới, mã hóa.

Answer 11

Bài kiểm tra đơn vị là phần tin cậy nhỏ nhất và duy nhất mà bạn có thể tự mình hoàn thành. Đó là những gì quan trọng, lặp đi lặp lại xây dựng một lá chắn chống lại hồi quy và độ lệch spec, không phải cách bạn thực sự tích hợp nó vào kiến ​​trúc hướng đối tượng của bạn.

Answer 12

tôi dẫn một nhóm các đội ngoài khơi quá. Giả sử chúng tôi có một bộ kiểm tra đơn vị ... nhưng nó không có nghĩa là nhiều. :) Vì vậy, chúng tôi dựa nhiều hơn vào chức năng và kiểm tra chất lượng. Vấn đề kế thừa với thử nghiệm đơn vị là bạn có kiến ​​thức hoàn hảo về các chức năng và bạn tin tưởng các nhà phát triển. Trong thế giới thực, thật khó để giả định ..

Answer 13

Thử nghiệm đơn vị: Thử nghiệm được thực hiện cho một đơn vị hoặc một phần mềm nhỏ nhất. Xong để xác minh xem nó có đáp ứng được đặc tả chức năng của nó hay cấu trúc thiết kế dự định của nó hay không.