Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Enhancement: define failure rate for each mocked response

Offen
  • Stimmt etwas nicht?
#103 13 Kommentare 1 Reaktion 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
25/100
Issue-Typ
Feature
Klarheit
Muss geklärt werden
Aktivitätsstatus
Veraltet
Tech-Stack
csharp
Bereich
cli, devtools, testing

Rechercherichtung

Beginne damit, die Befehlszeilenverarbeitung für responses.json in ms-dev-proxy und den Code zu finden, der gemockte Antworten anwendet. Kläre, ob die angeforderte Arbeit den alternativen Pfad zur Responses-Datei, Ausfallraten pro Antwort oder beides umfasst, und definiere die Antwortkonfiguration und das beobachtbare Verhalten vor der Implementierung. Erledigt sollte dokumentierte Optionen und Tests enthalten, die die ausgewählten Szenarien abdecken.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.
Vorherrschende Sprache
C#
Sterne
833
Forks
90
Ø Merge
18 Std. 41 Min.
Gemergte PRs (30 T.)
45

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus dotnet/dev-proxy

Alle Issues in dotnet/dev-proxy

Ähnliche Issues

Weitere Issues zu C#

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.