dapr / docs

Dapr user documentation, used to build docs.dapr.io
https://docs.dapr.io
Creative Commons Attribution 4.0 International
987 stars 715 forks source link

Enhancement: Include example/s on how one should component test a container utilising DAPR. #4089

Open dgannon991 opened 3 months ago

dgannon991 commented 3 months ago

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 :)

hhunter-ms commented 2 months ago

@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?

dgannon991 commented 1 month ago

Hi @hhunter-ms, I'd looked through the site at https://docs.dapr.io/ and the only hit I could find for testing was specific to the PHP SDK (https://docs.dapr.io/developing-applications/sdks/php/php-app/php-unit-testing/)

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?)