This is a great question. There aren't as many simple approaches for this
as there are for testing service logic.
I generally do a couple of things:
1. Separate what is *injected* by the DependencyProvider from the part that
manages the lifecycle, and unit test them both independently. A very
limited example of this is the toy Travis webservice DP
the Nameko docs. The service interface (ApiWrapper) can be easily
instantiated using mock or fake objects and the unit tested against them.
2. Some limited functional testing of the DependencyProvider or Entrypoint
in situ, to make sure that it is working correctly. Most of the community
extensions (e.g. nameko-amqp-retry
are tested in this way.
For the functional testing there are several helpers that you may find
- Extract the bound instance of an extension from a container
Execute a service method on a running container without invoking the
entrypoint. Gives you back the return value of exception from the method.
Block until an entrypoint-decorated method is executed. Accepts a callback
so you can wait for specific args or return values.
- Like entrypoint_waiter but for any method on any object.
Hope that helps.
On Friday, June 15, 2018 at 4:07:25 PM UTC+1, Davis Kirkendall wrote:
Is there a preferred way for testing dependency providers and
Granted, the basic idea of nameko is to have dependency providers be the
layer into the outside world that is mocked out during testing, but in many
cases the providers themselves need quite complex logic (spawned managed
threads, deserialization of inbound data and so on).
So I'd be interested in the solutions out there especially since the story
for testing service logic (worker factory, dependency replacement and so
on) in nameko is really nice!