feat(dev): Add fixtures for testing traces_sampler#867
Conversation
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!
a89d220 to
90628bd
Compare
Extracted from #863.