Should we mock out socket.getfqdn and friends

[dimaqq]

Some charms use e.g. socket.getfqdn() to pass the unit hostname to the relation counterparts. I suspect that it's rather specific to k8s.

For example:

https://github.com/canonical/traefik-k8s-operator/blob/90b209c7435bf29600fcaed52be4d79c2816fc8f/lib/charms/traefik_k8s/v2/ingress.py#L753-L754

Not mocking it out means that test data is derived from the hostname of the machine on which the test is run.

[tonyandrewmeyer]

I'm not sure why Scenario would do this - it seems out of scope. There are lots of things that might need to get mocked out for any given charm - it seems like that's the responsibility of the charm's tests rather than the framework that simulates events. I'm not sure where you would draw the line - do we then also start mocking time, urllib and friends, subprocess, etc? Providing utilities for those seem like they belong with pytest (and plugins) or other test tools, and I don't think Scenario would bake those in.

Can you explain more why it would make sense to do this? Or maybe give an example of how you think it'd look?

[dimaqq]

I would certainly agree that the specific call is an implementation detail.

It's also true that having scenario mock out random things would we weird.

At the same time, having each charm sprinkle its respective tests with custom mocks for every lib they pull in doesn't seem great either.

Ideally the ingress lib would provide a fixture or a test double.

Another option would be to recognise a class of things, let's say "kubernetes common" and implement that as a fixture that can be explicitly applied in charm tests.

Yet another alternative would be to mock out the entire lib.

To take some examples from other domains:

• if code uses requests, there's responses mocking library
• for stralette, there's starlette.TestClient
• for django, there's pytest.Django

I think it would be valuable to agree at what level the problem should be solved (if at all).