Tôi nên vẽ ranh giới giữa kiểm tra đơn vị và kiểm tra tích hợp ở đâu? Họ có nên tách rời?

Tôi có một khung MVC nhỏ mà tôi đang làm việc. Cơ sở mã của nó chắc chắn không lớn, nhưng nó không chỉ là một vài lớp. Cuối cùng tôi đã quyết định thực hiện bài kiểm tra và bắt đầu viết bài kiểm tra cho nó (vâng, tôi biết tôi nên làm điều đó suốt, nhưng API của nó vẫn không ổn định cho đến bây giờ)

Dù sao, kế hoạch của tôi là làm cho nó cực kỳ dễ kiểm tra, bao gồm cả kiểm tra tích hợp. Một thử nghiệm tích hợp ví dụ sẽ đi một cái gì đó dọc theo các dòng này:

Đối tượng yêu cầu HTTP giả -> Khung MVC -> Đối tượng phản hồi HTTP -> kiểm tra phản hồi có đúng không

Bởi vì đây là tất cả có thể thực hiện được mà không cần bất kỳ công cụ trạng thái hoặc công cụ đặc biệt nào (tự động hóa trình duyệt, v.v.), tôi thực sự có thể làm điều này một cách dễ dàng với các khung kiểm tra đơn vị thông thường (tôi sử dụng NUnit).

Bây giờ là câu hỏi lớn. Chính xác thì tôi nên vẽ ranh giới giữa kiểm tra đơn vị và kiểm tra tích hợp? Tôi có nên chỉ kiểm tra một lớp tại một thời điểm (càng nhiều càng tốt) với các bài kiểm tra đơn vị không? Ngoài ra, các thử nghiệm tích hợp có nên được đặt trong cùng một dự án thử nghiệm như dự án thử nghiệm đơn vị của tôi không?

Tích hợp so với kiểm tra đơn vị

Bạn nên giữ các bài kiểm tra đơn vị của bạn và kiểm tra tích hợp của bạn hoàn toàn tách biệt. Kiểm tra đơn vị của bạn nên kiểm tra một điều và một điều duy nhất và hoàn toàn cô lập với phần còn lại của hệ thống của bạn. Một đơn vị được xác định một cách lỏng lẻo nhưng nó thường đi sâu vào một phương thức hoặc một chức năng.

Thật có ý nghĩa khi có các bài kiểm tra cho từng đơn vị để bạn biết các thuật toán của chúng được triển khai chính xác và ngay lập tức bạn biết điều gì đã sai ở đâu, nếu việc triển khai bị sai sót.

Vì bạn kiểm tra cách ly hoàn toàn trong khi kiểm tra đơn vị, bạn sử dụng các đối tượng còn sơ khai và giả để hành xử giống như phần còn lại của ứng dụng. Đây là nơi kiểm tra tích hợp đến. Kiểm tra tất cả các đơn vị cách ly là tuyệt vời nhưng bạn cần phải biết liệu các đơn vị có thực sự làm việc cùng nhau hay không.

Điều này có nghĩa là biết nếu một mô hình thực sự được lưu trữ trong cơ sở dữ liệu hoặc nếu một cảnh báo thực sự được đưa ra sau khi thuật toán X thất bại.

Hướng phát triển thử nghiệm

Lùi lại một bước và nhìn vào Phát triển hướng thử nghiệm (TDD), có một số điều cần tính đến.

1. Bạn viết bài kiểm tra đơn vị của bạn trước khi bạn thực sự viết mã khiến nó vượt qua.
2. Bạn thực hiện bài kiểm tra, viết mã vừa đủ để thực hiện điều này.
3. Bây giờ bài kiểm tra đã qua, đã đến lúc lùi lại một bước. Có bất cứ điều gì để tái cấu trúc với chức năng mới này tại chỗ? Bạn có thể làm điều này một cách an toàn vì mọi thứ được bao phủ bởi các bài kiểm tra.

Tích hợp trước so với Tích hợp trước

Kiểm tra tích hợp phù hợp với chu trình TDD này theo một trong hai cách. Tôi biết những người thích viết chúng trước. Họ gọi thử nghiệm tích hợp là thử nghiệm đầu cuối và xác định thử nghiệm từ đầu đến cuối là thử nghiệm hoàn toàn kiểm tra toàn bộ đường dẫn của một usecase (nghĩ đến việc thiết lập một ứng dụng, khởi động nó, đi đến bộ điều khiển, thực thi nó, kiểm tra kết quả, đầu ra, v.v ...). Sau đó, họ bắt đầu với bài kiểm tra đơn vị đầu tiên của mình, làm cho nó vượt qua, thêm một giây, làm cho nó vượt qua, v.v ... Dần dần ngày càng nhiều phần của bài kiểm tra tích hợp vượt qua cho đến khi tính năng kết thúc.

Phong cách khác là xây dựng một bài kiểm tra đơn vị tính năng bằng bài kiểm tra đơn vị và thêm các bài kiểm tra tích hợp được coi là cần thiết sau đó. Sự khác biệt lớn giữa hai điều này là trong trường hợp kiểm tra tích hợp, trước tiên bạn buộc phải nghĩ đến thiết kế của một ứng dụng. Kiểu này không đồng ý với tiền đề rằng TDD là về thiết kế ứng dụng cũng như về thử nghiệm.

Thực tiễn

Trong công việc của tôi, chúng tôi có tất cả các thử nghiệm của chúng tôi trong cùng một dự án. Có nhiều nhóm khác nhau. Công cụ tích hợp liên tục chạy những gì được đánh dấu là đơn vị kiểm tra đầu tiên. Chỉ khi những người thành công chậm hơn (vì họ thực hiện các yêu cầu thực tế, sử dụng cơ sở dữ liệu thực, v.v.) thì các thử nghiệm tích hợp cũng được thực hiện.

Chúng tôi thường sử dụng một tệp thử nghiệm cho một lớp bằng cách này.

Cách đọc được đề nghị

1. Phát triển phần mềm hướng đối tượng, được hướng dẫn bởi các bài kiểm tra Cuốn sách này là một ví dụ cực kỳ hay về phương pháp thử nghiệm tích hợp đầu tiên
2. Nghệ thuật kiểm thử đơn vị, với các ví dụ trong dot.net Về kiểm thử đơn vị, với các ví dụ trong dot.net: D Cuốn sách rất hay về các nguyên tắc đằng sau kiểm thử đơn vị.
3. Robert C. Martin trên TDD (Bài viết miễn phí): Đừng đọc hai bài báo đầu tiên anh ấy liên kết ở đó.

Điều quan trọng trong bất kỳ chiến lược thử nghiệm nào là Bảo hiểm thử nghiệm - tức là có thể cho thấy tất cả các chức năng đang được thử nghiệm.

Tôi nói chung, và trừ khi bạn có các yêu cầu cụ thể ngược lại (ví dụ DO178 Cấp A, IEC61508 SIL 4, v.v.) không xuất hiện trong trường hợp của bạn, thì nếu bạn có thể kiểm tra toàn bộ chức năng của lớp hoặc mô-đun (và chứng minh rằng bạn có) ở cấp hệ thống, sau đó kiểm tra cấp hệ thống là đủ. Và cứ thế mà xuống. Kiểm tra đơn vị chỉ cần thiết khi bạn chưa bao gồm kiểm tra thêm.

Chính xác thì tôi nên vẽ ranh giới giữa kiểm tra đơn vị và kiểm tra tích hợp?

Thử nghiệm tích hợp thường dễ dàng hơn, nhanh hơn và rẻ hơn, vẽ đường càng xa càng tốt ...

Tôi có nên chỉ kiểm tra một lớp tại một thời điểm (càng nhiều càng tốt) với các bài kiểm tra đơn vị không?

Nó phụ thuộc vào phạm vi, một lần nữa ... theo định nghĩa, một bài kiểm tra đơn vị đang kiểm tra một đơn vị. Nhưng nếu bạn có thể kiểm tra đầy đủ một mô-đun đầy đủ trong một lần, thì nếu bạn muốn, hãy làm như vậy. Bạn đang có hiệu lực hoàn thành một số bài kiểm tra đơn vị trong một lần nhấn.

Ngoài ra, các thử nghiệm tích hợp có nên được đặt trong cùng một dự án thử nghiệm như dự án thử nghiệm đơn vị của tôi không?

Không có lý do cơ bản tại sao không ... trừ khi thử nghiệm cấp cao hơn được thực hiện bởi một người thử nghiệm độc lập, tại thời điểm đó bạn chỉ nên phát hành một thiết bị thực thi và tối thiểu.

Khi tôi có các dự án nhỏ, tôi chỉ đưa tất cả các bài kiểm tra vào cùng một dự án. Vì một dự án lớn hơn sẽ có những sự chia tách này, tôi chỉ đảm bảo rằng có thể trêu chọc họ nếu cần thiết.

Với các bài kiểm tra đơn vị, tôi thường chỉ kiểm tra một lớp (SUT) trong một tệp.