I've not used Hypothesis, but looking at your question on hypothesis-users,
I think there are a few things you can try:
1. Does your service under test actually use RabbitMQ? If not, removing the
`rabbit_config` will stop Nameko trying to set up the vhosts.
2. From your comment at the end, I guess you're most interested in testing
the paths through the service method, rather then the
entrypoints/dependency providers? If so, you might find the
`worker_factory` a useful helper. It gives you a service instance, so you
can invoke service methods on it as regular methods on an object. If you
did this you wouldn't need RabbitMQ to be running even if your service has
3. From what I understand, the problem is that Hypothesis is setting the
random number generation at the process level, while another thread is in
the process of using it . This is surely a general problem for any program
that uses threads (green or otherwise), but there are probably a couple
ways you can work around it:
a) Update the vhost_pipeline
overriding or patching) to use something other than random.choice to
generate the random names.
b) Make sure Hypothesis sets random.seed(0) *before* the vhost pipeline
thread starts running.
Hope that helps,
On Friday, June 8, 2018 at 11:25:56 AM UTC+1, tom....@sohonet.com wrote:
Hypothesis is a property based testing library. I tried to test Nameko
service code with it, but had problems due to the fact it edits global
state (random.seed(0)), while nameko does setup with eventlet.
I've asked this question on hypothesis-users
If anyone has used Hypothesis to test Nameko service code, I'd love to
hear how you got on.