-
Notifications
You must be signed in to change notification settings - Fork 57
Add change supporting unit testing #537
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
- Support orchestrators and entities
Will fix linting once the implementation is closer to complete |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with this approach. Can we add some sample code that shows how to write unit tests (and make sure it works)?
…com/Azure/azure-functions-durable-python into andystaples/add-unit-testing-change
I have deliberately excluded the tests from running in the GitHub YAML. The reasons for this are numerous, primarily because the tests are run from the project directory of this project, not from the sample app directories, which leads to two problems:
The "correct" way to run the tests from the samples project would be to add a separate GitHub workflow/action to build and test the samples projects independently. I can do this, if there is enough value there, but I have verified that this sample code tests successfully locally when built and run from the sample app directories. |
My prayer is that someday I will understand how module imports in Python work. I get horribly confused every time I run into issues like this.
I think it's worth doing. I sometimes like to think that a feature doesn't actually work unless there is a test proving that it works. |
Done! |
* Expose OrchestratorGeneratorWrapper in SDK
This PR add support for unit testing Durable client functions, orchestrators, and entities without any change needed to azure-functions-python-library or azure-functions-python-worker.
This is achieved by augmenting the handler returned by the Durable extension into a callable class, with a property storing the original user-defined function.
This way, the worker is still able to process these function types as normal, by passing the context to be parsed by our extension code, but when these new handlers are returned during unit testing, users can access the original function for testing.
Syntactically, here is what that looks like:
Currently, for non-Durable functions and Durable activity functions, even though the Functions decorators replace the original function (see the "Meaning of decorators" section here), users can access the original function either by calling the function directly:
or by using methods on the wrapped version like so:
This PR would change the signature of this boiler plate code slightly. We would not preserve the behavior of calling the function directly, and the way to access the original function would look like this:
Discussion about whether this solution is adequate and possible improvements is welcome.