dotnet / dotnet/dev-proxy

Enhancement: define failure rate for each mocked response

Đang mở
#103 13 bình luận 1 reaction 0 người được giao Xem trên GitHub
needs spec
Ngôn ngữ chính
C#
Star
831
Fork
89
Merge trung bình
12 giờ 1 phút
Pull request đã merge (30 ngày)
23

Mô tả

### Background

Currently, I am researching if we may use the ms-dev-proxy as a tool to support us in integration/manual/QA tests for our apps, and mocking responses is just the perfect functionality we could use 😉.

### Idea

1. Currently the ms-dev-proxy will look for `responses.json` file in the working directory which is just perfect to keep mock related to the app in the projects folder. What I was thinking is maybe ms-dev-proxy could have a new option that would allow specifying the relative path to the `response.json` with mocks to be used. Maybe something like `-r --responses-file-path` (optional). The aim for this would be to have different test scenarios with different mocks for the same app and then use them as part of integration tests. That way I could keep something like
```
.
├── MyApp
├── TestScenarios
│ ├── groups-fail-timeout-responses.json
│ └── throttle-responses.json
```

In this case, each integration test could start the ms-dev-proxy giving different `responses.json` mocks as param.

TBH this is very low 😉 (and probably stupid) idea as the current workaround I have for it is:
- keep `responses.json` in subfolders and run the ms-dev-proxy in the subfolder with correct mocks as working directory
- the test may just copy/paste the needed `responses.json` file to be used for this test.

2. Second idea I had (sorry for adding 2 ideas in one issue, I am a bit lazy and running out of time 😝), is to give possibility to define the failure rate for each mocked response in case we are mocking error response.

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

Hướng nghiên cứu

Bắt đầu bằng cách xác định phần xử lý dòng lệnh cho responses.json trong ms-dev-proxy và mã áp dụng các phản hồi giả lập. Làm rõ liệu công việc được yêu cầu có bao gồm đường dẫn thay thế đến tệp phản hồi, tỷ lệ lỗi cho từng phản hồi hay cả hai, sau đó xác định cấu hình phản hồi và hành vi có thể quan sát trước khi triển khai. Điều kiện hoàn thành cần bao gồm các tùy chọn được ghi tài liệu và các bài kiểm thử bao quát những kịch bản đã chọn.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Đánh giá

Công nghệ
csharp
Lĩnh vực
cli, devtools, testing
Loại issue
Tính năng
Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức độ hoạt động
Đình trệ
Độ rõ ràng
Cần làm rõ
Mức phù hợp với người mới
25/100

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.