Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Consider shorter syntax for result stubbing, for use in unit-tests in other systems on how those systems handle faults #17

Open
reisenberger opened this issue Jan 20, 2019 · 4 comments
Assignees
Labels
feature help wanted Extra attention is needed new API

Comments

@reisenberger
Copy link
Member

All current overloads are of the form:

MonkeyPolicy.InjectX(/* what to inject */, Double injectionRate, bool enabled) // or similar Func variants for injectionRate and enabled

Unit tests are likely to always want to inject the fault/response (ie injectionRate: 1 and enabled: true). Propose: Add syntax overloads throughout, of the form:

MonkeyPolicy.InjectX(/* what to inject */)

which chain on to injectionRate: 1 and enabled: true.

Timing

Would be nice to have this before launch, as stubbing for unit-tests is a major use case we can advertise, as part of the launch

See also #16 . Makes sense to implement #16 before this.

@reisenberger reisenberger added help wanted Extra attention is needed feature new API labels Jan 20, 2019
@reisenberger reisenberger added this to the Initial launch milestone Jan 20, 2019
@reisenberger
Copy link
Member Author

Had ideas of possible alternatives to the previous comment - intending to post a follow-up comment when time available.

@reisenberger
Copy link
Member Author

Maybe we take this out of scope of the initial launch, so that we can get a first chaos-engineering version out.

Leaving the issue open, but removing the 'Initial launch' milestone

@reisenberger reisenberger removed this from the Initial launch milestone Mar 23, 2019
@mebjas
Copy link
Member

mebjas commented Apr 11, 2019

Wouldn't we want to test each overload with unit test and validate different scenarios for each combinations?

@reisenberger reisenberger changed the title Add shorter syntax for result stubbing, for unit-tests Consider shorter syntax for result stubbing, for unit-tests Jun 30, 2019
@reisenberger reisenberger changed the title Consider shorter syntax for result stubbing, for unit-tests Consider shorter syntax for result stubbing, for use in unit-tests in other systems on how those systems handle faults Jun 30, 2019
@reisenberger
Copy link
Member Author

Clarification: this issue is not about how we write unit tests within the Simmy repo on Simmy policies, but about how Simmy could be used as a tool to provide stub fault responses, for users to test their Polly policies in other apps. Similar to #16.

This #17 is about whether we want overloads defaulting to injectionRate: 1 and enabled: true, for the use case of always injecting the fault, for a unit-test. But maybe we don't need the extra overload - maybe it just adds extra API surface which would confuse the (majority) chaos use case. Maybe it is enough to demonstrate in a blog post/wiki page how one could use the existing syntax with injectionRate: 1 and enabled: true to stub a result in a unit test.

#16 is about whether InjectResult() would be a more neutral language for overloads than InjectFault. (In unit-testing, not every result you want to stub in is a fault.)

@vany0114 vany0114 self-assigned this Oct 22, 2019
@vany0114 vany0114 mentioned this issue Oct 23, 2019
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
feature help wanted Extra attention is needed new API
Projects
None yet
Development

No branches or pull requests

3 participants