2009-11-06 17 views
7

Tôi đã luôn luôn giả mạo/mocking/stubbing HttpContext bằng cách nào đó trong ASP.NET (dễ dàng hơn nhiều trong ASP.NET MVC/MonoRail).Tại sao giả sử HttpContext nếu nó có thể được xây dựng?

Nhưng tôi có thể thấy rằng HttpContext chính nó có thể được xây dựng dễ dàng, theo nghĩa đen với vài dòng mã.

var tw = new StringWriter(); 
var workerReq = new SimpleWorkerRequest("/webapp", @"c:\here\there\wwwroot", "page.aspx", tw); 
var context = new HtpContext(workerReq); 

Nếu chúng tôi sẽ quấn mã này vào một cái gì đó như thế này nó sẽ làm việc tốt, và có lẽ chúng ta thậm chí có thể làm cho ASPX sử dụng rằng:

using(Simulate.HttpContext()) { 
    HttpContext.Current.BlaBla; 
} 

Vì vậy, câu hỏi là:

  1. Lý do tại sao KHÔNG nên làm.
  2. Lý do tại sao cần thực hiện.
  3. Tại sao nó không được sử dụng rộng rãi (trên thực tế tôi không nhớ bất kỳ bài viết nào về nó).

Tôi nhớ một bài đăng mà Phill Haack đã xây dựng HttpContext bằng cách sử dụng Hacks phản chiếu.
Nhưng có vẻ như không cần thiết.

Chúc mừng,
Dmitriy.

Trả lời

5

Làm việc thử nghiệm rất đơn giản là tốt, nhưng bạn sẽ kiểm tra thành phần nào sử dụng HttpRequest.Files như thế nào? Theo tôi biết, không có API công khai nào cho phép bạn chỉ định điều này trên SimpleWorkerRequest. Thậm chí nếu bạn có thể tìm thấy một vị trí nơi bạn có thể thiết lập một thuộc tính HttpFileCollection, lưu ý rằng hàm tạo của nó là nội bộ, vì vậy bạn thậm chí không thể tạo một cá thể của kiểu đó.

HttpRequest.Files không phải là một mình trong vấn đề này, và trong thực tế có lẽ mọi thứ bao la hơn bạn không thể thử nghiệm với việc thực hiện HttpContext hiện hơn bạn thể thử nghiệm. Đây là nơi abstractions thực sự có ích.

2

Có một vài tình huống cần xem xét.

Trường hợp một: Bạn đang thử nghiệm đơn vị. bạn có một cái gì đó nhỏ, giống như một lớp quản lý truy cập vào bộ nhớ cache, và nó gọi HttpContent.Cache một cách rõ ràng. Trong trường hợp này, giả lập bối cảnh để bạn có thể xem những cuộc gọi nào đang được thực hiện và liệu chúng có đang hoạt động theo mong muốn của bạn hay không.

Trường hợp hai: Bạn đang thực hiện kiểm tra tích hợp, nơi bạn đang cố thử nghiệm một thứ gì đó lớn như tạo một trang phức tạp. Trong trường hợp này, hãy cho nó đối tượng HttpContent thực sự theo cách bạn đã tìm thấy. Kiểm tra tích hợp của bạn sẽ mô phỏng tốt hơn thời gian chạy thực.

+0

chế nhạo cũng là điều tuyệt vời để truy cập các điều kiện lỗi cụ thể. – dbn

0

Điều đó có thể làm việc, nhưng ...

  • Trước hết tôi thấy một số con đường, mà có thể khác nhau trong môi trường.
  • Thứ hai là nó cần một cái gì đó như IIS cài đặt?
  • Mất bao nhiêu thời gian để tạo? Nếu tôi có 100 bài kiểm tra cần nó và phải mất 1 giây, thì điều đó có nghĩa là thử nghiệm của tôi chạy khoảng phút hoặc lâu hơn và nó dẫn đến các nhà phát triển chạy thử nghiệm ít hơn.
  • Bạn có thể dễ dàng giả lập/thiết lập Bộ nhớ cache, Yêu cầu vv để tạo kịch bản thử nghiệm?

Chế nhạo/cuống có lẽ dễ dàng hơn.

EDIT

Tìm thấy một số mã nguồn cho HttpContext và SimpleWorkerRequest trong dự án Mono:

Những có thể cung cấp cái nhìn sâu sắc hơn về những gì đang xảy ra trong sáng tạo .

Tìm thấy một bài báo gì có thể hữu ích cũng như: ASP.NET CreateApplicationHost/SimpleWorkerRequest API Hole

Đó thực sự minh họa độc đáo mà chúng ta cần phải hiểu những gì đang xảy ra ở những đối tượng trước khi áp dụng chúng và phải mất thời gian. Mocking có vẻ dễ dàng hơn.

+0

PATHS: Tôi không nghĩ chúng thực sự đang được sử dụng. IIS: Tôi không nghĩ rằng nó là cần thiết quá. THỜI GIAN TẠO: Tôi cho rằng nó không nên dài hơn bất kỳ đối tượng phức tạp nào. Nhưng điểm cuối cùng (mockup Cache/Request) là một điểm tốt nhất. –

Các vấn đề liên quan