Hacktoberfest 2026:維護者為十月標記出來的 issue,仍然開放、適合新手。 瀏覽 Hacktoberfest issue

Enhancement: define failure rate for each mocked response

未關閉
#103 13 則留言 1 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
5/5
預估耗時
一週以上
新手友好度
25/100
Issue 類型
功能
描述清晰度
需要釐清
活躍度
停滯
技術堆疊
csharp
領域
cli, devtools, testing

研究方向

首先找出 ms-dev-proxy 中處理 responses.json 的命令列邏輯,以及套用模擬回應的程式碼。釐清要求的工作是否包括替代的回應檔案路徑、每個回應的失敗率,或兩者皆包括,然後在實作前定義回應設定與可觀察的行為。完成條件應包括已記錄的選項,以及涵蓋所選情境的測試。

由索引模型根據 Issue 內容生成。

描述

needs spec
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.
  1. 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.
主要語言
C#
星號
832
分支
90
平均合併
17 小時 54 分鐘
30 天內合併 PR
47

環境準備

  • 提供 Dockerfile 或 Docker Compose 檔案
  • 沒有 Pull Request 範本
  • 閱讀貢獻指南

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

dotnet/dev-proxy 的其他 Issue

查看 dotnet/dev-proxy 的全部 Issue

相似的 Issue

更多 C# Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。