Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Enhancement: define failure rate for each mocked response

Ouverte
  • Quelque chose ne va pas ?
#103 13 commentaires 1 réaction 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
25/100
Type d'issue
Fonctionnalité
Clarté
À clarifier
Activité
À l'abandon
Stack technique
csharp
Domaine
cli, devtools, testing

Piste de recherche

Commencez par localiser la gestion de la ligne de commande pour responses.json dans ms-dev-proxy ainsi que le code qui applique les réponses simulées. Déterminez si le travail demandé inclut le chemin alternatif vers le fichier de réponses, des taux d’échec par réponse, ou les deux, puis définissez la configuration des réponses et le comportement observable avant l’implémentation. La définition de terminé doit inclure des options documentées et des tests couvrant les scénarios sélectionnés.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.
Langage dominant
C#
Étoiles
832
Forks
90
Merge moyen
18 h 41 min
PR mergées (30 j)
45

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de dotnet/dev-proxy

Toutes les issues de dotnet/dev-proxy

Issues similaires

Plus d'issues C#

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.