feat(dev): Add fixtures for testing traces_sampler
#867
Conversation
lobsterkatie
force-pushed
the
kmclb-traces-sampler-test-env
branch
2 times, most recently
from
530bbb2 to
a89d220
Compare
| pytest-cov==2.8.1 | ||
| jsonschema==3.2.0 | ||
| pyrsistent==0.16.0 # TODO(py3): 0.17.0 requires python3, see https://github.com/tobgu/pyrsistent/issues/205 | ||
| mock # for testing under python < 3.3 |
There was a problem hiding this comment.
Instead of doing this please just use the pytest monkeypatch fixture
There was a problem hiding this comment.
I'm not sure how you mean. I do see how you could use monkeypatch for mock.patch.object calls, but how would you handle getting mock.Mock instances when you need them?
There was a problem hiding this comment.
I don't know how you're going to use mock but I've just been creating my own stub classes. I find a lot of mock's behavior too magical wrt attribute access on the mock obj
Sure, if you'd rather. I've been getting coaching to keep my PR's a manageable size, so I've tried to pull out from the main PR anything which could be thought of on its own and/or which was a non-behavior-changing prerequisite for the main changes. I recognize that for that to work there's got to be more cross-referencing and possibly more faith that such prereq changes are going to be used in a reasonable way. Still trying to find the balance, I guess. (And very open to advice in this arena!) Perhaps rather than mushing these fixtures back into the main PR, I could pull the tests out of that and include them here, and just mark them all xfail for the moment? |
That's also fine, though I think anything under 400loc is reviewable. |
| @pytest.fixture(name="FunctionMock") | ||
| def function_mock(): | ||
| """ | ||
| Just like a mock.Mock object, but one which always passes an isfunction | ||
| test. | ||
| """ | ||
|
|
||
| class FunctionMock(mock.Mock): | ||
| def __init__(self, *args, **kwargs): | ||
| super(FunctionMock, self).__init__(*args, **kwargs) | ||
| self.__class__ = FunctionType | ||
|
|
||
| return FunctionMock |
There was a problem hiding this comment.
I don't know how you're going to use mock but I've just been creating my own stub classes. I find a lot of mock's behavior too magical wrt attribute access on the mock obj
Here, for instance:
def test_passes_custom_samling_context_from_start_transaction_to_traces_sampler(
FunctionMock, sentry_init, DictionaryContaining
):
traces_sampler = FunctionMock()
sentry_init(traces_sampler=traces_sampler)
start_transaction(custom_sampling_context={"dogs": "yes", "cats": "maybe"})
traces_sampler.assert_any_call(
DictionaryContaining({"dogs": "yes", "cats": "maybe"})
)Would rather not have to rewrite the machinery of tracking calls.
There was a problem hiding this comment.
def test_passes_custom_samling_context_from_start_transaction_to_traces_sampler(
sentry_init
):
sampler_calls = []
sentry_init(traces_sampler=sampler_calls.append)
start_transaction(custom_sampling_context={"dogs": "yes", "cats": "maybe"})
assert sampler_calls == [{"dogs": "yes", "cats": "maybe"}]Unless you need to account for additional keys or calls I would go with this...
There was a problem hiding this comment.
Feel free to add... I am not entirely sure why people keep using this stuff but I don't want to fight it.
There was a problem hiding this comment.
Okay, in the interest of time I'm going to leave it for now, but that's an interesting pattern to know about, thanks!
lobsterkatie
force-pushed
the
kmclb-traces-sampler-test-env
branch
from
a89d220 to
90628bd
Compare
Extracted from #863.