Tạo Bài kiểm tra Đơn vị trên lớp CRUD của Ứng dụng, làm cách nào tôi có thể làm cho các bài kiểm tra độc lập?

Vì vậy, tôi đang cố gắng thực hiện các Bài kiểm tra đơn vị của mình càng nhiều càng tốt, nhưng nó trở nên rắc rối khi tôi thử nghiệm một số phương pháp Thêm / Xóa đơn giản.

Đối với phương thức add, về cơ bản tôi phải tạo một đối tượng giả và thêm nó, sau đó sau khi thử nghiệm thành công, tôi phải xóa đối tượng giả.

Và đối với thử nghiệm xóa, rõ ràng tôi phải tạo một đối tượng giả để tôi có thể xóa nó.

Như bạn có thể thấy nếu một bài kiểm tra thất bại, bài kiểm tra khác cũng sẽ thất bại, vì cả hai đều cần thiết.

Tương tự với một hệ thống mà bạn sẽ cần phải viết một bài kiểm tra rằng "Hủy đơn hàng" ... cũng cần một số thứ tự giả để hủy trước, điều này có đi ngược lại các hướng dẫn kiểm tra đơn vị không?

Làm thế nào là những trường hợp như thế này có nghĩa là phải được xử lý?

Chà, không có gì sai với những gì bạn đang làm. Nhiều bài kiểm tra có thể bao gồm cùng một mã; nó chỉ có nghĩa là một vấn đề sẽ khiến một số bài kiểm tra thất bại. Những gì bạn muốn tránh là các xét nghiệm phụ thuộc vào kết quả của các xét nghiệm khác. Tức là, kiểm tra xóa của bạn phụ thuộc vào kiểm tra thêm đã chạy, và do đó nếu bạn chạy kiểm tra xóa TRƯỚC KHI kiểm tra thêm của bạn, nó sẽ thất bại. Để tránh vấn đề đó, hãy đảm bảo rằng bạn có "bảng trắng" khi bắt đầu mỗi bài kiểm tra, để những gì xảy ra trong một bài kiểm tra nhất định không thể ảnh hưởng đến các bài kiểm tra tiếp theo.

Một cách tuyệt vời để làm điều đó là chạy thử nghiệm đối với cơ sở dữ liệu trong bộ nhớ.

Trong thử nghiệm thêm của bạn, tạo một cơ sở dữ liệu trống, thêm đối tượng và khẳng định rằng nó thực sự đã được thêm vào.

Trong thử nghiệm xóa của bạn, tạo cơ sở dữ liệu với đối tượng bạn sẽ xóa trong đó. Xóa đối tượng và xác nhận rằng nó đã bị xóa.

Thổi bay cơ sở dữ liệu trong mã xé của bạn.

Sử dụng giao dịch.

Nếu bạn đang sử dụng cơ sở dữ liệu hỗ trợ các giao dịch, thì hãy chạy từng thử nghiệm trong một giao dịch. Phục hồi giao dịch vào cuối thử nghiệm. Sau đó, mỗi bài kiểm tra sẽ để lại cơ sở dữ liệu không thay đổi.

Có, để hủy đơn hàng, trước tiên bạn sẽ phải tạo một đơn hàng. Tốt rồi. Thử nghiệm trước tiên sẽ tạo một đơn hàng, sau đó hủy đơn hàng, sau đó xác minh rằng đơn hàng đã bị hủy.

Bạn đang làm tốt Nguyên tắc cơ bản và duy nhất của kiểm thử đơn vị là bao quát mọi đường dẫn mã bạn có, vì vậy bạn có thể tin tưởng rằng mã của bạn đang làm những gì nó phải làm và tiếp tục thực hiện sau khi thay đổi và tái cấu trúc. Giữ các bài kiểm tra đơn vị nhỏ, đơn giản và đơn mục đích là một mục tiêu đáng giá, nhưng nó không phải là cơ bản. Có một bài kiểm tra gọi hai phương thức liên quan đến API của bạn không phải là vấn đề, thực tế, như bạn chỉ ra, điều đó thường là cần thiết. Hạn chế của việc có các bài kiểm tra dư thừa chỉ là chúng mất nhiều thời gian hơn để viết, nhưng vì hầu hết mọi thứ đang phát triển, đây là một sự đánh đổi mà bạn phải thực hiện mọi lúc, và giải pháp tốt nhất gần như không bao giờ là một trong những điểm cực đoan.

Các kỹ thuật kiểm thử phần mềm vô cùng đa dạng và bạn càng tự học về chúng, bạn sẽ bắt đầu thấy nhiều hướng dẫn khác nhau (và đôi khi mâu thuẫn). Không có "cuốn sách" nào để đi qua.

Tôi nghĩ rằng bạn đang ở trong một tình huống mà bạn đã thấy một số hướng dẫn cho các bài kiểm tra đơn vị nói những điều như

• Mỗi thử nghiệm phải độc lập và không bị ảnh hưởng bởi các thử nghiệm khác
• Mỗi bài kiểm tra đơn vị nên kiểm tra một điều, và chỉ một điều
• Kiểm tra đơn vị không nên nhấn cơ sở dữ liệu

và như thế. Và tất cả những điều đó đều đúng, tùy thuộc vào cách bạn xác định test bài kiểm tra đơn vị ' .

Tôi sẽ định nghĩa một "bài kiểm tra đơn vị" giống như: "một bài kiểm tra thực hiện một phần chức năng cho một đơn vị mã, tách biệt với các thành phần phụ thuộc khác".

Theo định nghĩa đó, những gì bạn đang làm (nếu nó yêu cầu thêm bản ghi vào cơ sở dữ liệu trước khi bạn có thể chạy thử nghiệm) hoàn toàn không phải là 'thử nghiệm đơn vị', mà nhiều hơn thường được gọi là 'thử nghiệm tích hợp'. (Một thử nghiệm đơn vị thực sự, theo định nghĩa của tôi, sẽ không đánh vào cơ sở dữ liệu, vì vậy bạn sẽ không cần thêm bản ghi trước khi xóa nó.)

Một thử nghiệm hội nhập sẽ thực hiện chức năng sử dụng nhiều thành phần (chẳng hạn như một giao diện người dùng và một cơ sở dữ liệu), và hướng dẫn mà sẽ được áp dụng để kiểm tra đơn vị không nhất thiết phải áp dụng đối với các xét nghiệm hội nhập.

Như những người khác đã đề cập trong câu trả lời của họ, những gì bạn đang làm không nhất thiết là sai ngay cả khi bạn làm những việc trái với một số hướng dẫn kiểm tra đơn vị. Thay vào đó, hãy thử suy luận về những gì bạn thực sự đang thử nghiệm trong mỗi phương pháp thử nghiệm và nếu bạn thấy rằng bạn cần nhiều thành phần để đáp ứng thử nghiệm của mình và một số thành phần yêu cầu cấu hình trước, hãy tiếp tục và thực hiện.

Nhưng trên hết, hãy hiểu rằng có nhiều loại kiểm thử phần mềm (kiểm tra đơn vị, kiểm tra hệ thống, kiểm tra tích hợp, kiểm tra khám phá, v.v.) và không thử áp dụng hướng dẫn của một loại cho tất cả các loại khác.

Đây chính xác là lý do tại sao một trong những hướng dẫn khác là sử dụng giao diện. Nếu phương thức của bạn lấy một đối tượng thực hiện một giao diện thay vì triển khai lớp cụ thể, bạn có thể tạo một lớp không phụ thuộc vào phần còn lại của cơ sở mã.

Một cách khác là sử dụng khung mô phỏng. Điều này cho phép bạn dễ dàng tạo các loại đối tượng giả này có thể được truyền vào phương thức bạn đang thử nghiệm. Có thể bạn có thể phải tạo một số triển khai còn sơ khai cho lớp giả, nhưng nó vẫn tạo ra một sự tách biệt với việc thực hiện thực tế và những gì bài kiểm tra có liên quan.

Như bạn có thể thấy nếu một bài kiểm tra thất bại, bài kiểm tra khác cũng sẽ thất bại, vì cả hai đều cần thiết.

Vì thế?

... không phải điều này đi ngược lại các hướng dẫn kiểm tra đơn vị?

Không.

Làm thế nào là những trường hợp như thế này có nghĩa là phải được xử lý?

Một số thử nghiệm có thể độc lập và tất cả đều thất bại vì cùng một lỗi. Điều đó thực sự bình thường. Rất nhiều bài kiểm tra có thể - gián tiếp - kiểm tra một số chức năng phổ biến. Và tất cả đều thất bại khi chức năng chung bị hỏng. Không có gì sai với nó.

Kiểm thử đơn vị được định nghĩa là các lớp chính xác để chúng có thể dễ dàng chia sẻ mã, giống như một bản ghi giả phổ biến được sử dụng để kiểm tra cập nhật và xóa.

Bạn có thể sử dụng khung giả hoặc sử dụng 'môi trường' với cơ sở dữ liệu trong bộ nhớ. Lớp cuối cùng là một lớp nơi bạn có thể tạo mọi thứ bạn cần để vượt qua bài kiểm tra, trước khi bài kiểm tra chạy.

Tôi thích cái cuối cùng - người dùng có thể giúp bạn nhập một số dữ liệu để các bài kiểm tra của bạn trở nên gần nhất với thế giới thực.