Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add a set_unchecked method that can be used to do mocking in tests #33

Merged
merged 3 commits into from
Oct 6, 2018

Conversation

nikomatsakis
Copy link
Member

This PR adds a set_unchecked method available for input and memoized queries. (I would expect that after #18 is fixed, it would work for all queries.) It permits one to forcibly set a query's value without running the code. This is useful for mocking purposes in writing tests.

@nikomatsakis
Copy link
Member Author

Impatient, so just gonna merge =)

We can bikeshed the name at some point though. I debated between mock, set_unchecked, and mock_unchecked.

@nikomatsakis
Copy link
Member Author

just realized travis as broken, fixed it I think

@matklad
Copy link
Member

matklad commented Oct 5, 2018

LGTM, but a couple of questions:

Because we use empty inputs, set unchecked is forever, I think? This seems like it could be surprising, but maybe not?

Should we have an issue for the general testing infrastructure? I expect it would be useful to get some sort of the trace of the query, to make sure it does’t eval too much after invalidation, for example?

@nikomatsakis
Copy link
Member Author

@matklad

Because we use empty inputs, set unchecked is forever, I think? This seems like it could be surprising, but maybe not?

I was wondering about it too. I was imagining that one would use this primarily in a "revision-less" fashion -- you would basically mock up some inputs and then test that you get the output you expect. But I can also imagine wanting to do fancier tests, where you mock up some inputs, test that you get the output you expect, and then alter the mocked inputs, and test (e.g.) that the output doesn't wind up being recomputed. This kind of bleeds into your next question...

Should we have an issue for the general testing infrastructure? I expect it would be useful to get some sort of the trace of the query, to make sure it does’t eval too much after invalidation, for example?

...I agree that could be useful, yes. I don't really know what that would look like or what we will want 100% yet. I would think it's best to see what we find we want while iterating.

@nikomatsakis nikomatsakis merged commit 1e5f409 into salsa-rs:master Oct 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants