Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Enhancement: define failure rate for each mocked response

Aperta
  • Qualcosa non va?
#103 13 commenti 1 reazione 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
csharp
Ambito
cli, devtools, testing

Direzione di ricerca

Inizia individuando la gestione della riga di comando per responses.json in ms-dev-proxy e il codice che applica le risposte simulate. Chiarisci se il lavoro richiesto include il percorso alternativo del file delle risposte, tassi di errore per risposta o entrambi, quindi definisci la configurazione delle risposte e il comportamento osservabile prima dell'implementazione. Il completamento dovrebbe includere opzioni documentate e test che coprano gli scenari selezionati.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.
Lingua principale
C#
Stelle
832
Fork
90
Merge medio
17h 54m
PR unite (30g)
47

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di dotnet/dev-proxy

Tutte le issue di dotnet/dev-proxy

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.