dotnet / dotnet/dev-proxy

Enhancement: define failure rate for each mocked response

オープン
#103 コメント 13 件 リアクション 1 件 担当者 0 名 GitHub で見る
needs spec
主要言語
C#
スター
832
フォーク
89
平均マージ
12時間 1分
マージ済み PR(30日)
23

説明

### 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.

コントリビューションガイド

コントリビューションガイドを開く

調査の方向性

まず、ms-dev-proxy で responses.json を処理するコマンドライン処理と、モックされたレスポンスを適用するコードを探します。依頼された作業に代替のレスポンスファイルパス、レスポンスごとの失敗率、またはその両方が含まれるかを明確にし、実装前にレスポンス設定と観測可能な動作を定義します。完了条件には、文書化されたオプションと、選択したシナリオを網羅するテストを含める必要があります。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
csharp
領域
cli, devtools, testing
issue の種類
機能追加
難易度
5/5
見積もり時間
1週間以上
活発さ
停滞
明瞭さ
説明が足りない
初心者へのやさしさ
25/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。