You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What content needs to be created or modified?
An example guide for how we can mock the DAPR sidecar/method calls in order to be able to component test a single container without having to spin up all downstream dependencies (in our case, a pub/sub queue, a database and a keyvault.) as this leans heavily towards integration testing at that point, and is something we were hoping DAPR would help us solve as an issue.
Describe the solution you'd like
A new section is added to the "Developing applications" tree which covers component testing, from the early stages of testing your first DAPR component, to examples of testing several inter-related DAPR components.
Additional context
Thanks for the chat at kubecon and the suggestion to raise this issue in response :)
The text was updated successfully, but these errors were encountered:
@dgannon991 I posted this issue in the components-contrib channel on Discord to see if I could get any help - Could you add some information on the goals of this docs issue? We do have developer documentation (readmes) that capture how to test everything, and often we'd just point users to the regular Dapr docs. How would the example guide capture what isn't already captured between the readmes and Dapr docs?
Basically we use a few DAPR methods in one of our code to talk to a database and an azure keyvault. When it comes to testing these things, the only way we've managed it so far is full scale integration testing (which is expensive and time consuming!) We'd hoped there was a better way that we were missing, such that we were only testing our code/logic, and not the fact that DARP is doing what it should. Does that make sense? (I worry it's gone a bit rambly, happy to clarify with some more concrete examples if that's helpful?)
What content needs to be created or modified?
An example guide for how we can mock the DAPR sidecar/method calls in order to be able to component test a single container without having to spin up all downstream dependencies (in our case, a pub/sub queue, a database and a keyvault.) as this leans heavily towards integration testing at that point, and is something we were hoping DAPR would help us solve as an issue.
Describe the solution you'd like
A new section is added to the "Developing applications" tree which covers component testing, from the early stages of testing your first DAPR component, to examples of testing several inter-related DAPR components.
Additional context
Thanks for the chat at kubecon and the suggestion to raise this issue in response :)
The text was updated successfully, but these errors were encountered: