Nameko web fixtures

googlegroup
1

Hi,

I've got a question about testing against an http endpoint on a service.

We have a script that accesses our service over http. The script can take a
parameter telling it the URL of the server.

If we want to write an integration test where the script accesses the
service, we imagine running the service with fixtures like this:

@pytest.fixture
def config(web_config, rabbit_config):
    config = {}
    # sets WEB_SERVER_ADDRESS
    config.update(web_config)
    # sets AMQP_URI, username, vhost
    config.update(rabbit_config)
    return config

@pytest.fixture
def service(container_factory, config):
    container = container_factory(ExampleService, config)
    container.start()
    return container

Now we can see two options for how to connect the script to this service:

1) We can try to mock out the http request code in the script to use the
web_session
<https://github.com/nameko/nameko/blob/4a90e784b4293ac07798c0a5ba3a68f8057b4d02/nameko/testing/pytest.py#L338>
fixture
2) We can read the WEB_SERVER_ADDRESS in the config set by the web_config
<https://github.com/nameko/nameko/blob/4a90e784b4293ac07798c0a5ba3a68f8057b4d02/nameko/testing/pytest.py#L319>
fixture

#2 looks easier to implement, but the worry is that this makes assumptions
about what may be the private API of the nameko fixture system.
For example, without reading the source code, it wasn't obvious that the
web_session fixture is just a wrapper around a requests session.
Maybe that could change in future, and bypassing web_session would then
have been the wrong approach?

Or is there another better way to go about this?

Thanks,
Tom

2

Hi Tom,

I think it's fair to say that the server address config key is public api
so reading it out of the config sounds fine to me. you might also look at
one of the "lower level" fixtures, e.g. `web_config_port`.

Best,
David

···

On Thursday, 19 April 2018 12:05:18 UTC+1, tom....@sohonet.com wrote:

Hi,

I've got a question about testing against an http endpoint on a service.

We have a script that accesses our service over http. The script can take
a parameter telling it the URL of the server.

If we want to write an integration test where the script accesses the
service, we imagine running the service with fixtures like this:

@pytest.fixture
def config(web_config, rabbit_config):
    config = {}
    # sets WEB_SERVER_ADDRESS
    config.update(web_config)
    # sets AMQP_URI, username, vhost
    config.update(rabbit_config)
    return config

@pytest.fixture
def service(container_factory, config):
    container = container_factory(ExampleService, config)
    container.start()
    return container

Now we can see two options for how to connect the script to this service:

1) We can try to mock out the http request code in the script to use the
web_session
<https://github.com/nameko/nameko/blob/4a90e784b4293ac07798c0a5ba3a68f8057b4d02/nameko/testing/pytest.py#L338&gt;
fixture
2) We can read the WEB_SERVER_ADDRESS in the config set by the web_config
<https://github.com/nameko/nameko/blob/4a90e784b4293ac07798c0a5ba3a68f8057b4d02/nameko/testing/pytest.py#L319&gt;
fixture

#2 looks easier to implement, but the worry is that this makes assumptions
about what may be the private API of the nameko fixture system.
For example, without reading the source code, it wasn't obvious that the
web_session fixture is just a wrapper around a requests session.
Maybe that could change in future, and bypassing web_session would then
have been the wrong approach?

Or is there another better way to go about this?

Thanks,
Tom