Làm cách nào để thử nghiệm đơn vị và tích hợp theo kiểu BDD trong ASP.NET MVC?

Question

Tôi đang học Behavior Driven Development với ASP.NET MVC và, dựa trên a post từ Steve Sanderson, hiểu rằng BDD có thể có nghĩa là, ít nhất, các loại kiểm tra sau đây: đơn vị riêng lẻ của mã & tương tác UI. Một cái gì đó tương tự được đề cập trong this post. Tôi có cần hai khung kiểm tra khác nhau nếu tôi muốn cả thử nghiệm đơn vị và tích hợp?

• kho Đơn vị kiểm tra, kiểm soát, & dịch vụ sử dụng một khung cảnh/đặc điểm kỹ thuật, giống như MSpec. Kết quả thử nghiệm với điều này sẽ hữu ích cho nhóm phát triển.

• Kiểm tra hành vi hoàn chỉnh (tích hợp) bằng cách sử dụng khung/khi/sau đó, như SpecFlow với Watin. Kết quả của thử nghiệm này sẽ hữu ích cho khách hàng của tôi.

Video tôi đã xem cho đến nay bằng BDD chỉ bị giới hạn kiểm tra hành vi của thực thể mà không kiểm tra hành vi của kho, bộ điều khiển, v.v ... Có dự án mẫu nào tôi có thể thấy cả thử nghiệm Đơn vị và Tích hợp tự động bằng cách sử dụng phương pháp BDD?

Answer 1

Cá nhân tôi sử dụng SpecFlow để kiểm tra các tính năng cụ thể (ví dụ: "Người dùng tạo hồ sơ công ty mới"), nơi tôi thỉnh thoảng (nhưng không phải lúc nào) sử dụng Watin. Để kiểm tra respositories của tôi, hoặc các lớp dịch vụ, tôi sẽ sử dụng unit/integration tests với NUnit. Kiểm thử tích hợp là khi tôi cần nói chuyện với cơ sở dữ liệu trong khi thử nghiệm, đơn vị là khi tôi chỉ chạy mã trong đối tượng mục tiêu được thử nghiệm mà không có tương tác bên ngoài.

Tôi có thể nói rằng bạn không cần sử dụng khuôn khổ BDD cho các thử nghiệm không phải UI của bạn. Bạn có thể nếu bạn muốn, nhưng không có quy tắc cứng và nhanh về điều này. Nếu bạn định làm điều này, tôi khuyên bạn nên tạo nhiều hơn một dự án cho các bài kiểm tra của bạn. Việc tách chúng là một ý tưởng tốt, thay vì sau đó trộn tất cả các thử nghiệm vào một dự án. Bạn có thể đặt tên cho chúng:

MyProject.Tests.Features < - Đối với BDD Kiểm tra SpecFlow.

MyProject.Tests.Integration < - Đối với kiểm tra truy cập cơ sở dữ liệu bên ngoài .

MyProject.Tests.Unit

Nếu bạn không muốn sử dụng hai khung BDD, bạn vẫn có thể sử dụng MSTest/NUnit một cách BDD. Ví dụ, this bài viết blog mô tả một quy ước đặt tên tốt đẹp gần với BDD, nhưng nhằm kiểm tra đơn vị MSTest/NUnit. Bạn có thể sử dụng điều này cho các thử nghiệm không SpecFlow của bạn khi thử nghiệm của bạn những thứ như kho.

Tóm lại - bạn không phải sử dụng SpecFlow và MSpec trong thử nghiệm của bạn, nhưng nếu bạn làm thế, thì tôi khuyên bạn nên dùng thử các dự án riêng biệt.

Answer 2

Tôi thường đồng ý với những gì Jason đã đăng.

Bạn có thể muốn chia thông số kỹ thuật của mình thành hai loại, kiểm tra hệ thống/tích hợp và đơn vị cấp. Bạn có thể mô tả cả hai loại với bất kỳ khung công tác nào, nhưng hãy nhớ rằng các phương pháp chỉ mã (NUnit, MSpec, v.v.) yêu cầu một nhà phân tích nghiệp vụ có khả năng viết C#. SpecFlow/Gherkin có thể là một cách tiếp cận tốt hơn nếu bạn muốn liên quan đến các nhà phân tích và người dùng bằng văn bản chi tiết kỹ thuật.Vì cú pháp và quy tắc (Given, When, Then) rất dễ hiểu và viết các đặc tả từ góc nhìn của người dùng dễ dàng ghi lại sau khi được đào tạo ít. Đó là tất cả về việc thu hẹp khoảng cách giao tiếp và giúp người dùng giúp nhóm của bạn hình thành ngôn ngữ phổ biến trong miền của bạn.

Tôi khuyên bạn nên có thông số kỹ thuật hỗ trợ cả hai hoạt động "bên ngoài trong" và "trong ra ngoài". Bạn có thể bắt đầu với đặc tả SpecFlow "bên ngoài" được viết bởi người dùng/nhà phân tích/chủ sở hữu sản phẩm và làm việc theo cách của bạn từ "chưa được thực hiện" sang "xanh" bằng cách viết mã thực tế. Mã hỗ trợ tính năng này được phát triển bằng cách sử dụng TDD với một khuôn khổ hướng kỹ thuật hơn như MSpec (phần "bên trong").

Đây là kho lưu trữ sử dụng MSpec cho cả kiểm tra đơn vị và tích hợp: https://github.com/agross/duplicatefinder.