# Testing dependency providers

**URL:** <https://discourse.nameko.io/t/testing-dependency-providers/260>\
**Category:** googlegroup\
**Created:** [June 15, 2018, 3:07pm UTC](https://discourse.nameko.io/t/testing-dependency-providers/260 "2018-06-15T15:07:25Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Davis\_Kirkendall](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.nameko.io/davis_kirkendall/32/18_2.png) [@Davis\_Kirkendall](https://discourse.nameko.io/u/Davis_Kirkendall)\
**Post date:** [June 15, 2018, 3:07pm UTC](https://discourse.nameko.io/t/testing-dependency-providers/260/1 "2018-06-15T15:07:25Z")

</div>

Is there a preferred way for testing dependency providers and entrypoints?

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!

---

<div class="post-metadata">

**Author:** ![mattbennett](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.nameko.io/mattbennett/32/13_2.png) [@mattbennett](https://discourse.nameko.io/u/mattbennett)\
**Post date:** [June 18, 2018, 6:08am UTC](https://discourse.nameko.io/t/testing-dependency-providers/260/2 "2018-06-18T06:08:38Z")

</div>

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  
\<[https://github.com/nameko/nameko/blob/master/docs/examples/travis.py&gt](https://github.com/nameko/nameko/blob/master/docs/examples/travis.py&gt); in  
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  
\<[https://github.com/nameko/nameko-amqp-retry/blob/master/test/test\_events.py&gt;\](https://github.com/nameko/nameko-amqp-retry/blob/master/test/test_events.py&gt;%5C))  
are tested in this way.

For the functional testing there are several helpers that you may find  
useful:

get\_extension  
\<[https://github.com/nameko/nameko/blob/master/nameko/testing/utils.py#L16&gt](https://github.com/nameko/nameko/blob/master/nameko/testing/utils.py#L16&gt);  
- Extract the bound instance of an extension from a container  
entrypoint\_hook  
\<[https://github.com/nameko/nameko/blob/2a3584a6c9a3082ab7fa1319c63f9e062d3461bb/nameko/testing/services.py#L20&gt](https://github.com/nameko/nameko/blob/2a3584a6c9a3082ab7fa1319c63f9e062d3461bb/nameko/testing/services.py#L20&gt); -  
Execute a service method on a running container without invoking the  
entrypoint. Gives you back the return value of exception from the method.  
entrypoint\_waiter  
\<[https://github.com/nameko/nameko/blob/master/nameko/testing/services.py#L84&gt](https://github.com/nameko/nameko/blob/master/nameko/testing/services.py#L84&gt); -  
Block until an entrypoint-decorated method is executed. Accepts a callback  
so you can wait for specific args or return values.  
wait\_for\_call  
\<[https://github.com/nameko/nameko/blob/master/nameko/testing/waiting.py#L40&gt](https://github.com/nameko/nameko/blob/master/nameko/testing/waiting.py#L40&gt);  
- Like entrypoint\_waiter but for any method on any object.

Hope that helps.

Matt.

> **···**
>
> 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  
> > entrypoints?
> > 
> > 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!